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 any other. 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): glibc-2.3.2-27.9 How reproducible: Always 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: in setup_fopen exiting setup_fopen entering tester1 exiting tester1 entering tester2 and hangs there Expected Results: The program should have given this output: in setup_fopen exiting setup_fopen entering tester1 exiting tester1 entering tester2 exiting tester2 without lingering. Additional info:
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.