From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21283 invoked by alias); 4 Dec 2007 23:25:52 -0000 Received: (qmail 21223 invoked by uid 22791); 4 Dec 2007 23:25:50 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Dec 2007 23:25:37 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id C06B73BE43; Tue, 4 Dec 2007 15:25:35 -0800 (PST) Subject: Re: RFA: Fix check for no-saved-pc From: Michael Snyder To: Mark Kettenis Cc: drow@false.org, gdb-patches@sourceware.org In-Reply-To: <200712041805.lB4I5KsC028209@brahms.sibelius.xs4all.nl> References: <1196462431.2501.164.camel@localhost.localdomain> <20071130230045.GA24809@caradoc.them.org> <1196473044.2501.189.camel@localhost.localdomain> <200712041805.lB4I5KsC028209@brahms.sibelius.xs4all.nl> Content-Type: text/plain Date: Tue, 04 Dec 2007 23:25:00 -0000 Message-Id: <1196809890.2501.287.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00065.txt.bz2 On Tue, 2007-12-04 at 19:05 +0100, Mark Kettenis wrote: > > From: Michael Snyder > > Date: Fri, 30 Nov 2007 17:37:24 -0800 > > > > On Fri, 2007-11-30 at 18:00 -0500, Daniel Jacobowitz wrote: > > > On Fri, Nov 30, 2007 at 02:40:31PM -0800, Michael Snyder wrote: > > > > There's a check in get_prev_frame to see if the next saved pc > > > > is zero. I think it has an off-by-one error, and is checking > > > > for the pc of the wrong frame. > > > > > > Mark K. and I have had roughly a month's worth of discussion on this > > > check over the last two years; it's where it is on purpose. Here's > > > the last conversation: > > > > > > http://sourceware.org/ml/gdb-patches/2006-05/msg00196.html > > > http://sourceware.org/ml/gdb-patches/2006-07/msg00296.html > > > > All right. Then let's leave that test alone, and add another > > test, much later on, to detect and report this situation. > > > > Here's my revised patch. Testsuites un-affected. > > > > As before, the effect of this change is to have gdb print > > a more informative message instead of a meaningless zero-frame. > > It's not meaningless; it's a very valuable hint that the stack has been > corrupted. My poor choice of words. What I meant was more like, one is a "hint" and the other is an explicit statement. A person does not need to know what this hint means if gdb tells them explicitly. > You'll get very similar output if youd chosen some random > value instead of zero when you corrupted the stack. Why is zero special? A good question, and the only answer I can give is "it just is". You are right, this is a special case -- but it seems, in practice, to be one that comes up fairly frequently, eg. when a wild pointer or out of bounds array writes zeroes over a region of stack. Why zero and not some other value? Just because it is fairly common to write zeroes into something, I guess. The real answer is because we or our users see it a lot. > If your answer to that question is something like: "because on arm the > outermost frame gets marked by a zero pc", No, that's not it at all. This has nothing to do with any particular architecture (although some may or may not be more vulnerable to it than others). This has nothing to do with any deliberate attempt to "mark" the outermost frame. OTOH, one context in which it does come up is when there has been no attempt at all to mark the outermost frame -- as eg. the first frame of a new thread -- and the frame's memory comes up full of zeros (either because that's the default value for un-initialized memory, or because the thread library initializes it to zero). GDB looks where the function prologue says the return address should be stored, and finds zero.