Bug 97671 - fprintf hangs, and/or syslog crashes due to dynamic loading bug
fprintf hangs, and/or syslog crashes due to dynamic loading bug
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
9
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
http://skuld.phear.org/myso.c
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-18 20:09 EDT by Henrý Þór Baldursson
Modified: 2016-11-24 09:53 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-03 01:18:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Testcase for file-io streams bug (1.64 KB, text/plain)
2003-06-18 20:11 EDT, Henrý Þór Baldursson
no flags Details

  None (edit)
Description Henrý Þór Baldursson 2003-06-18 20:09:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
I have written a little testcase preloadable DSO. This code simply displays a
problem I'm having with using fdopen() and subsequent syslog() and fprintf()
calls. When run on my RH9 box, this code will print the two syslog messages but
the fprintf() call will hang.

If you remove the first syslog() call, where you announce that the open64
function has been called, the second syslog() call will cause a segmentation
fault in malloc(), bt:
(gdb) bt
#0  0x420744f5 in _int_malloc () from /lib/tls/libc.so.6
#1  0x4207360b in malloc () from /lib/tls/libc.so.6
#2  0x42069937 in open_memstream () from /lib/tls/libc.so.6
#3  0x420da7fb in vsyslog () from /lib/tls/libc.so.6
#4  0x420da75f in syslog () from /lib/tls/libc.so.6
#5  0x4001785a in open64 (filename=0xbffffabf "/etc/issue", flags=0)
    at myso.c:69
#6  0x0804944f in __fxstat64 ()
#7  0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb)

Any information would be good.


Version-Release number of selected component (if applicable):
glibc-2.3.2-27.9

How reproducible:
Always

Steps to Reproduce:
1. compile the myso.o object (gcc -g -ggdb -c myso.c)
2. link it into a dso (ld -Bshareable -o my.so myso.o -ldl)
3. run cat /etc/issue preloaded with it (LD_PRELOAD="$PWD/my.so" cat /etc/issue
    

Actual Results:  The two syslog messages are delivered, but the code apparently
hangs on the fprintf

Expected Results:  The code should work fine, allowing access to /etc/issue.

Additional info:

I have tested a similar testcase under redhat 8.0, and had a friend test this
particular testcase on his Immunix machine with glibc-2.2-12_imnx_28. Both tests
ran fine without hangs.
Comment 1 Henrý Þór Baldursson 2003-06-18 20:11:11 EDT
Created attachment 92471 [details]
Testcase for file-io streams bug
Comment 2 Christian Leber 2003-06-18 21:16:39 EDT
I also tested this Problem and came to the conclusion that it's either a glibc
or nptl problem, because it also doesn't work with nptl 0.37 (and glibc from cvs
at the time of the release or from the TIMESTAMP Ulrich Drepper gave) but it
works with nptl 0.40, so it was fixed somewhere between.
(even the binary modul from a Redhat 9 system works with the nptl 0.40 packages
I use, the same for 0.42 and 0.47)

Regards
Christian Leber
Comment 3 Ulrich Drepper 2003-10-02 04:41:57 EDT
Repeat after bugzilla reload:

This is not a bug.  The symbols _init and _fini like all symbols starting with _
(with a few documented exceptions) are reserved.  The correct way to do what you
want is to use the mechanism clearly documented in the gcc manual, namely using
the constructor and destructor function attributes.  No bug.
Comment 4 Henrý Þór Baldursson 2003-10-02 06:38:05 EDT
Makes no difference if I name the functions _init/_fini, if I call them jack()
and  jill() and just attribute them into the .init and .fini sections
respectively, they still run compiled on environments other than Red Hat Linux
9, but not anywhere else.

If this is not a bug, why does the testcase using these attributes not work on
Red Hat Linux 9's libc, but works on the latest Libc's and older like Christian
Leber showed.

Anyway, I work around this issue simply by specifying LD_ASSUME_KERNEL="2.4.19"
in the linker's environment.
Comment 5 Ulrich Drepper 2003-10-03 01:18:22 EDT
First of all: chose better word or I'll completely ignore you.

Second, you can *NOT* chose whatever names you want.  I already said that each
and every symbol starting with an underscore belongs to the system.

Third, _init and _fini are special symbols used by the runtime.

If it ever worked, then by accident.  The new thread runtime got much more
sophisticated and bugs like this show.

Fix your code.

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