[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 6 Dec 2000 06:34:52 -0800 (PST)
Hi, I'm having a problem with dlclose which I'm having
a hard time solving, but I've narrowed it down to the
fact that l_addr is not correct when elf/_dl_close()
is attempting to call the _fini routine of my shared
lib. (in the block for an "old-sytle destructor" ~line
156 [glibc v2.2]). I know the load address is wrong
here because I dumped it out with _dl_debug_message
and it doesn't jive with the load address that
LD_DEBUG=files shows where the shared lib was loaded.
Anyway the result is that it jumps off to somewhere,
but not my _fini, and segfaults.
I also have a case that works, the only difference
being that in the failure case I dlsym a routine and
call it in the shared lib.
The shared lib and the main program are both compiled
with: gcc version 2.96 20000731 (Red Hat Linux 7.0),
I'm running a Linux 2.4-test11 kernel on x86, and
obviously have glibc2.2 installed.
here is some sample output that may (or not :) help:
generating link map
06981: dynamic: 0x40018fb8 base: 0x40017000
06981: entry: 0x400175f4 phdr: 0x40017034
06981: calling fini:
[these are entries i added to _dl_close to figure out
what was going on]
06981: calc fini addr...
06981: has fini func:0x809d164
Note that the dll handle I got back *was* 0x809bcd0,
and d_ptr looks right, when I dlsym look up _fini
myself it is 0x40017e24, but when 0xe24 is added to
the l_addr (which is where it calls) bad things happen
I guess I'm looking for suggestions on how to furthur
research this, for one I'm going to try to narrow down
the test case to be able to send a small example. But
I'm wondering how l_addr got changed between the time
it was set in _dl_map_object_from_fd and when I called dlclose()?
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
|[Prev in Thread]
||[Next in Thread]|