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.
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) Regards Christian Leber
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 Leber showed. 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.