[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Jan 2013 13:35:23 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com, pierre@...entlife.com
Subject: Re: dladdr()
On Mon, Jan 21, 2013 at 07:58:20AM +0100, pierre wrote:
>
> > is dladdr otherwise working correctly for you now?
>
> In the simple example I provided, it always works.
> I have added loaded modules with conflicting symbols
> and dladdr() also works as expected.
>
> But for my main application (which populates backtraces
> with dladdr), musl dladdr() works in DEBUG mode and
> crashes in RELEASE mode. I did not have time to isolate
> the problem in a reproducible code snippet but I will
> let you know when I have done that.
The only non-static memory access dladdr makes are:
1. Reading the map ranges for each loaded DSO from the DSO list.
2. Reading the hash table pointers for the matching DSO (if one was
found), and:
2a. If there's a sysv hash table, just reading the number of symbols
directly from it.
2b. If there's only a gnu hash table, reading the gnu hash table and
counting the number of symbols.
3. Reading the locations of the symbol and string tables from the DSO
record.
4. Reading each symbol table entry to find the best match for the
argument.
5. Storing results to the caller-provided Dl_info buffer.
I don't see how any of these could crash without memory already having
been corrupted. Do you have a test case I could run, or have you tried
building libc with -g and examining the crash in gdb to see where it
happens?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
