This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Reference counting bug in ld-linux.so.2 (2.1.2, 2.1.3, 2.1.9x, et. al.)


Hello,

My name is Allen Bauer, and I am one of the senior developers for the Kylix
project here at Borland. I have come across what I think is a serious flaw
in how the dynamic loader handles references to shared objects. Attached is
a simple test case that demonstrates the problem.  Basically the scenario is
this:

Executable dynamically loads lib-a.so which requires lib-b.so and lib-c.so.
lib-b.so also requires lib-c.so. Then the executable dynamically loads
lib-b.so. Later, it decides to unload lib-b.so, then finally unloads
lib-a.so. This will cause lib-c.so to be left in memory with a lone
reference count of 1. This can lead to all sorts of interesting behaviours
later when other shared objects (or even these same ones) get re-loaded. I
have had the lazy-binding system fail miserably.

To demonstrate this copy the attached tarball and untar. Then simply "cd
libc-bug" and run make. This should build all the .so's, the executable and
run it. The program will output information regarding what it is about to
do. Simply press return to proceed to each step.  Please note that calling
dlsym and calling the entry points is not really nessesary to reproduce the
bug. They are just there to verify that the correct shared objects were
loaded and working.  This is currently a serious show-stopper for us. I also
think this could be a serious problem for other Linux developers.

Allen Bauer.

Delphi/C++Builder/Kylix Sr. Staff Engineer.

Delphi/C++Builder/Kylix IDE R&D Manager.


loader-bug.tar.gz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]