Bug 39963
| Summary: | dlopen() calls seem to crash program that worked on RH7.0 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Erik J Burckart <ejburcka> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | Aaron Brown <abrown> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | fweimer, jakub |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-05-10 13:13:21 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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). |
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.