From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2646 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: dladdr() Date: Tue, 22 Jan 2013 08:51:51 -0500 Message-ID: <20130122135151.GQ20323@brightrain.aerifal.cx> References: <20130116125119.GA27914@port70.net> <50F6B818.1070807@gmail.com> <20130116164943.GD20323@brightrain.aerifal.cx> <50F6E698.3070604@gmail.com> <20130121020335.GO20323@brightrain.aerifal.cx> <1358751500.2196.20.camel@6-core> <20130121183523.GP20323@brightrain.aerifal.cx> <1358836066.2172.45.camel@6-core> <20130122130730.GB10600@port70.net> <1358862044.2172.216.camel@6-core> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1358862731 7443 80.91.229.3 (22 Jan 2013 13:52:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Jan 2013 13:52:11 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2647-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 22 14:52:27 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TxeGz-0008Us-V3 for gllmg-musl@plane.gmane.org; Tue, 22 Jan 2013 14:52:22 +0100 Original-Received: (qmail 19619 invoked by uid 550); 22 Jan 2013 13:52:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 19608 invoked from network); 22 Jan 2013 13:52:04 -0000 Content-Disposition: inline In-Reply-To: <1358862044.2172.216.camel@6-core> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2646 Archived-At: 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