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:
#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)
#3 0x08115bb3 in DosLoadModule (errbuf=0xbffff1d0 "", errbufsz=255,
modname=0x813a8e3 "libhttpdapi.so", hmod=0xbfffefbc) at ldshrobj.c:61
#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)
#10 0x4003d576 in __dlopen_check (file=0x81f2a90 "/usr/lib/archive.so", mode=257)
#11 0x08115adf in DosLoadModule (errbuf=0xbffff0f0 "", errbufsz=255,
modname=0x81f2a90 "/usr/lib/archive.so", hmod=0xbffff0ec) at ldshrobj.c:61
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
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).