Re: GDB Frame Filter - handling corrupt stack

[Phil Muldoon <pmuldoon@redhat.com>]

On 09/09/14 13:26, Simeon S wrote:


It's a fairly simple filter, so I don't see much wrong with that.
 
>
> When the gdb "backtrace" command is issued, frames are decorated
> followed by a gdb crash. This is what the last output from gdb is:
>
>     UNIX ERR:tcsetattr:Input/output error
>     Segmentation fault (core dumped)

I'd love to see a backtrace of this.  It is not related to your issue,
but it is a bug in the frame filters.  It should print the error
message below:

> The stack seems to be corrupt which is what I suspect is causing the
> crash. If the frame filter is disabled, the last line of the
> "backtrace" command is:
>
>     Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Yeah at this point the stack looks clobbered, or some kind of bug
internal to GDB has occurred.

> I haven't looked into why the stack is corrupt - all the frames of
> interest to me are there.  Is there a way to catch this condition to
> avoid crashing? I am not interested in any of the corrupt frames -
> what is in the stack is enough.

No not really.  Someone else may have an idea.

> I guess I am looking for a mechanism to stop gdb iterating over
> further frames if it detects a corrupt/invalid frame.  The
> documentation does say that gdb has to iterate over all stack frames
> though.

Even though the documentation does indeed say that, you can always
slice/trim the iterator that is handed to the frame filter and return
the sliced iterator.  The trick is finding which frame would be the
corrupted one and slicing appropriately.  See the itertools Python
module for iterator tools (including slicing).

Cheers

Phil