Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 97515 - fopen (via dlsym) hangs after syslog call
fopen (via dlsym) hangs after syslog call
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-06-16 19:29 EDT by Henrý Þór Baldursson
Modified: 2016-11-24 10:22 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-17 11:37:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Program for reproducing the bug (1.53 KB, application/octet-stream)
2003-06-16 19:31 EDT, Henrý Þór Baldursson
no flags Details

  None (edit)
Description Henrý Þór Baldursson 2003-06-16 19:29:55 EDT
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):

How reproducible:

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:
Comment 1 Henrý Þór Baldursson 2003-06-16 19:31:00 EDT
Created attachment 92438 [details]
Program for reproducing the bug
Comment 3 Jakub Jelinek 2003-06-17 11:37:02 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.