From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31292 invoked by alias); 16 Dec 2007 20:06:23 -0000 Received: (qmail 31283 invoked by uid 22791); 16 Dec 2007 20:06:22 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 16 Dec 2007 20:06:18 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id lBGK6B5l020900; Sun, 16 Dec 2007 21:06:11 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id lBGK6AXD018398; Sun, 16 Dec 2007 21:06:10 +0100 (CET) Date: Sun, 16 Dec 2007 20:08:00 -0000 Message-Id: <200712162006.lBGK6AXD018398@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: msnyder@specifix.com CC: drow@false.org, gdb-patches@sourceware.org In-reply-to: <1197486323.32169.94.camel@localhost.localdomain> (message from Michael Snyder on Wed, 12 Dec 2007 11:05:23 -0800) Subject: Re: RFA: Fix check for no-saved-pc References: <1196462431.2501.164.camel@localhost.localdomain> <20071130230045.GA24809@caradoc.them.org> <1196473044.2501.189.camel@localhost.localdomain> <200712041805.lB4I5KsC028209@brahms.sibelius.xs4all.nl> <1196809890.2501.287.camel@localhost.localdomain> <1197486323.32169.94.camel@localhost.localdomain> 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/msg00216.txt.bz2 > From: Michael Snyder > Date: Wed, 12 Dec 2007 11:05:23 -0800 > > Ping? Bleah, I tried to find a window of a bit more than 15 minutes to think about a reply for a week and a half and failed :(. > > > 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. It doesn't really add much more information: ? 0x00000000 foo isn't really less explicit than Saved pc is zero and words have a much bigger tendency to be ambiguous than factual information. That said, I don't really object to explicitly stating why we are terminating the backtrace, as long as the zero-pc stackframe is still visible and accessable. And we need to complain somewhat loudly otherwise people won't even notice something is wrong and won't fix the buffer overflows in their broken code. > > > 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. Well, I guess a common failure scenario could be using memset() on a buffer allocated on the stack and specifying the wrong size. But in my experience other values are just as common. People probably just don't notice because in that case we continue the backtrace until we eventually hit zero. > > 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). Yes, if you fall off the stack, I can imagine you hit zeroes much more often. I've repeatedly stated that people should fix their threading libraries to explicitly mark the end of the stack such that this doesn't happen, or that we should change GDB such that we terminate the stack at the thread entry point, much like we do for main(). I really don't want to cripple GDB because people think that's too difficult. Yes, I think your diff cripple GDB. The zero-pc frame might have useful information that could help me track down the memory corruption. > > GDB looks where the function prologue says the return address > > should be stored, and finds zero. Or GDB might just be confused and look in the wrong place.