This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Reference counting bug in ld-linux.so.2 (2.1.2, 2.1.3, 2.1.9x, et. al.)
- To: <libc-alpha at sources dot redhat dot com>
- Subject: Reference counting bug in ld-linux.so.2 (2.1.2, 2.1.3, 2.1.9x, et. al.)
- From: "Allen Bauer" <kylix_rd at borland dot com>
- Date: Wed, 18 Oct 2000 16:25:32 -0700
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