This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: Fix check for no-saved-pc
> From: Michael Snyder <msnyder@specifix.com>
> 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.