Red Hat Bugzilla – Bug 97515
fopen (via dlsym) hangs after syslog call
Last modified: 2016-11-24 10:22:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
OK. This bug is driving me insane.
I think theres a problem with the dynamic loader in glibc-2.3.2-27.9
The program in the URL, http://skuld.phear.org/syslog_ld.tgz, compiles and runs
on Red Hat Linux 8.0 and other Linuxes. But when run on my Red Hat 9 machine, it
hangs in the fopen call in the tester2() function. Seemingly due to the syslog()
call. I am able to reproduce it compiling with the shared objects, but if I try
to use -L/usr/lib/debug, I can not.
The program basically loads libc.so.6 and stores a pointer to fopen. A tester1
function is used to test the fopen call. Another function, tester2, which
exactly the same as tester1, except it calls syslog() just before calling the
function pointer to fopen, hangs at fopen on Red Hat Linux 9 systems, but not on
This program is just a simple reproduction proggie I made to find a problem I'm
seeing in a DSO I made which wraps the file open library calls. I know it's
dysfunctional and ugly, but as I said -- it's only a reproduction program.
Can anyone please shed some light on this problem I'm having?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. expand the syslog_ld.tgz tarball (tar -xzf syslog_ld.tgz)
2. cd into the syslog_ld/ directory (cd syslog_ld/)
3. compile the program (gmake)
4. run the program (./tester)
Actual Results: The program outputs:
and hangs there
Expected Results: The program should have given this output:
Created attachment 92438 [details]
Program for reproducing the bug
Your testcase is broken. Unless you use LD_ASSUME_KERNEL=2.4.19 or earlier in
the environment, /lib/tls/libc.so.6 is used, not /lib/libc.so.6 (and even
on RHL8 and earlier, /lib/i686/libc.so.6 is used often too).
You are dlopen'ing /lib/libc.so.6, which means that unless the program has been
already dynamically linked with /lib/libc.so.6, you have two copies of libc,
which is never going to work.
You can use dl_iterate_phdr function to look at currently loaded libraries,
or in most cases you can just dlsym (RTLD_NEXT, "something") in the library
which overrides something.