Bug 39963 - dlopen() calls seem to crash program that worked on RH7.0
Summary: dlopen() calls seem to crash program that worked on RH7.0
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-09 21:02 UTC by Erik J Burckart
Modified: 2016-11-24 15:18 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2001-05-10 13:13:21 UTC

Attachments (Terms of Use)

Description Erik J Burckart 2001-05-09 21:02:00 UTC
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


#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.

Comment 1 Erik J Burckart 2001-05-09 21:04:21 UTC
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.)

Comment 2 Jakub Jelinek 2001-05-10 07:30:59 UTC
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.

Comment 3 Erik J Burckart 2001-05-10 12:29:41 UTC
That works.  Thanks for your help.

Comment 4 Jakub Jelinek 2001-05-10 12:51:11 UTC
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.

Comment 5 Erik J Burckart 2001-05-10 12:54:16 UTC
I am investigating and will let you know what I find.  Thanks again for your help.

Comment 6 Erik J Burckart 2001-05-10 13:07:31 UTC
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?

Comment 7 Jakub Jelinek 2001-05-10 13:13:16 UTC
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).

Comment 8 Jakub Jelinek 2001-07-23 15:42:23 UTC
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).

Note You need to log in before you can comment on or make changes to this bug.