[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 22 Jan 2013 08:51:51 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: dladdr()
On Tue, Jan 22, 2013 at 02:40:44PM +0100, pierre wrote:
> Nagy,
>
> > instead of 'debug mode' vs 'release mode' the
> > config.mak with compiler flags/architecture/..
> > for the two cases
> > instead of 'crash' the details of the caught
> > signal, backtrace, memory map etc
> > a link to the source code or a minimal example
> > can help too
>
> Since I already said that I would provide this
> information later (I also have a job) I wonder
> what the purpose of these repeated calls is.
>
> PLEASE READ THE WHOLE THREAT before adding your
> grain of salt.
Apparently one or more of us missed a few details in the previous
emails when replying, but neither of us is out to attack you or
anything like that. I just wanted to understand whether there was some
detail I was missing that might be a bug in musl, or whether the crash
was caused by things outside our control.
> > i'm not sure how populating backtrace with
> > dladdr works
>
> By finding the symbols that match each IP
> (Instruction Pointer) address.
>
> > sounds suspicious
>
> I am impressed by the value of this argument.
>
> > how do you get your backtrace?
>
> By following stack frames. I am curious to learn
> what better way you will find less "suspicious".
I think his comment was that, in the event the stack has been smashed,
following the stack frames is likely (almost certain) to lead you to
destinations
Also, depending on what you're doing, it might not even be valid.
Since DWARF2 is used for debugging nowadays, musl is normally built
with -fomit-frame-pointer, so there won't be frame pointers to help
you follow the stack frames out of libc functions, in case the crash
happened inside a libc function. There also won't be DWARF2
information except in debug builds, and even if it is there, it's
normally (unless you change CFLAGS) just available to the debugger
rather than mapped into the program for introspection purposes.
Anyway, my purpose, and I believe nsz's purpose, in asking questions
was so that we could both (1) better evaluate whether there might be a
bug in musl related to this report, and (2) give you better
information about musl that might help you determine why your code
isn't doing what you want it to.
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.
