From Bugzilla Helper: User-Agent: Mozilla/4.51 [en] (WinNT; U) Description of problem: The program in question worked on rh6.1, 6.2, 7.0 as well as 7.0 with all the updates and a 2.4 kernel. When taking any of the old binaries or recompiling on rh7.1, I see stacks that look like the following: (gdb) where #0 0x40030d6e in __pthread_getspecific (key=1) at specific.c:130 #1 0x4003d989 in _dlerror_run (operate=0x4003d590 <dlopen_doit>, args=0xbfffef50) at dlerror.c:105 #2 0x4003d576 in __dlopen_check (file=0x813a8e3 "libhttpdapi.so", mode=257) at dlopen.c:53 #3 0x08115bb3 in DosLoadModule (errbuf=0xbffff1d0 "", errbufsz=255, modname=0x813a8e3 "libhttpdapi.so", hmod=0xbfffefbc) at ldshrobj.c:61 or #0 0x40030dec in libc_internal_tsd_get (key=_LIBC_TSD_KEY_MALLOC) at specific.c:190 #1 0x401330e7 in __libc_malloc (bytes=4) at malloc.c:2711 #2 0x40006341 in _dl_map_object_from_fd () at eval.c:41 #3 0x4000758d in _dl_map_object () at eval.c:41 #4 0x401c5bd6 in dl_open_worker (a=0xbfffef00) at dl-open.c:230 #5 0x4000dc83 in _dl_catch_error () at eval.c:41 #6 0x401c5f4e in _dl_open (file=0x81f2a90 "/usr/lib/archive.so", mode=-2147483391, caller=0x8115adf) at dl-open.c:362 #7 0x4003d5c5 in dlopen_doit (a=0xbffff070) at dlopen.c:39 #8 0x4000dc83 in _dl_catch_error () at eval.c:41 #9 0x4003d94b in _dlerror_run (operate=0x4003d590 <dlopen_doit>, args=0xbffff070) at dlerror.c:130 #10 0x4003d576 in __dlopen_check (file=0x81f2a90 "/usr/lib/archive.so", mode=257) at dlopen.c:53 #11 0x08115adf in DosLoadModule (errbuf=0xbffff0f0 "", errbufsz=255, modname=0x81f2a90 "/usr/lib/archive.so", hmod=0xbffff0ec) at ldshrobj.c:61 Additional info: I guess the bottom line is I am looking for info on what this bug is or where I can do even more research to figure out what changed that I need to code around or update.
I forgot to mention... in my queries the things I found that were similiar were #39803 (although that was with dlsym) and #25029 (although we do compile our binary with -lpthread as well as our library.)
Can you try export LD_ASSUME_KERNEL=2.2.5; before running your application? If the program clobbers %gs register, this would be expected behaviour.
That works. Thanks for your help.
Ok, can you investigate? Does the program/binary ever touch %gs (either source or objdump -dr could reveal this)? If yes, then it should be fixed (%gs is a system register for -lpthread), if not, then we need to investigate this further.
I am investigating and will let you know what I find. Thanks again for your help.
I did an `objdump -dr <bin or lib name> |grep "%gs"` for each of my binaries and libraries in the product and didn't find anything. I checked the source and found no references to it either. What else can I do to help?
If you could send me the program/library, it would be probably easiest, if you cannot do that, then e.g. ltrace and strace dumps might tell something, perhaps with short disassembly where it exactly died (something like disas $pc $pc+64 in gdb, plus info reg).
Oops, forgot to close this. The end of mail exchange was I believe: The issue is that ibmproxy binary does its own modify_ldt syscall in modify_ldt function called from ldt_init: ... 9749 modify_ldt(0x1, 0xbffffa34, 0x10) = 0 ... 9750 modify_ldt(0x11, 0xbffffa08, 0x10) = 0 ... The first one above is from glibc, the second is from ibmproxy. I guess they clash, since it dies soon after that call. I don't know what do you need ia32 segments in linux application for (modify_ldt is there primarily to support DOSemu and Wine I think). In case you really need it, you'd better of starting allocating them from the end (ie. 8191, 8190, ...) because -lpthread uses them from the first one up (currently up to 1023, but there is no guarantee this will not change in the future glibc versions, so be prepared).