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.