Bug 97515 - fopen (via dlsym) hangs after syslog call
Summary: fopen (via dlsym) hangs after syslog call
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 9
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL: http://skuld.phear.org/syslog_ld.tgz
Depends On:
TreeView+ depends on / blocked
Reported: 2003-06-16 23:29 UTC by Henrý Þór Baldursson
Modified: 2016-11-24 15:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-17 15:37:02 UTC
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 23:31 UTC, Henrý Þór Baldursson
no flags Details

Description Henrý Þór Baldursson 2003-06-16 23:29:55 UTC
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 23:31:00 UTC
Created attachment 92438 [details]
Program for reproducing the bug

Comment 3 Jakub Jelinek 2003-06-17 15:37:02 UTC
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.