Red Hat Bugzilla – Bug 97671
fprintf hangs, and/or syslog crashes due to dynamic loading bug
Last modified: 2016-11-24 09:53:12 EST
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:
#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)
#6 0x0804944f in __fxstat64 ()
#7 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
Any information would be good.
Version-Release number of selected component (if applicable):
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.
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.
Created attachment 92471 [details]
Testcase for file-io streams bug
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)
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.
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
Anyway, I work around this issue simply by specifying LD_ASSUME_KERNEL="2.4.19"
in the linker's environment.
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.