Re: Fix a crash when stepping and unwinding fails

Mark Kettenis
2006-02-21T21:34:42Z

> Date: Tue, 21 Feb 2006 15:57:48 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> On Tue, Feb 21, 2006 at 09:50:58PM +0100, Mark Kettenis wrote:
> > But if step_frame_id is equal to null_frame_id, we shouldn't be trying
> > to insert step-resume-breakpoints. It means that step_frame_id is
> > still uninitialized, since step_frame_id is initialized by:
> >
> > step_frame_id = get_frame_id (get_current_frame ());
> >
> > (or equivalent code), and unwinding from sentinel frame shoud always
> > yield a frame ID that's different from null_frame_id.
>
> It's this assumption I don't think is right. I have plenty of
> anecdotal evidence from yesterday that it's not right, in fact.
> If the prologue analyzer can't handle the code at $pc, then
> what do you expect it to put into the frame ID? Or if it thinks we
> are in the outermost frame?

But get_current_frame() should be the innermost frame when we execute
this code. So the prologue analyzer can't be involved here. However,
yes, it seems that step_frame_idd can end up as null_frame_id, if
get_current_frame() is also the outermost frame at the same time.

> > > That seems like a good change indeed, but probably wouldn't fix this
> > > problem.
> > >
> > > Hmm, what does frame_pc_unwind do when we've hit the last frame? I'm
> > > not sure it's meaningful.
> >
> > How can we hit the last frame? If we're hitting the last frame, where
> > did we come from?
> >
> > It may very well be that there are GDB bugs that make step_frame_id
> > equal to null_frame_id. If we can't trace those bugs right now, we
> > should probably sprinkle a few gdb_assert()'s around and try to solve
> > the issues when we hit those.
>
> We use the null frame ID to represent the outermost frame. If we can't
> find another frame outer to this one, then we assume this one is the
> outermost.

Yes, it seems there are issues here. The frame ID is supposed to be
unique for a particular frame, yet there's a possibility that two
distinct frames both end up with the null frame ID.

> Just to sketch out my example a bit more: the embedded OS I'm debugging
> lives in ROM. The application I've supplied to GDB lives in RAM. In
> some later stage of the project, hopefully, I will have GDB magically
> load some other ELF files (that I don't have yet) to cover the ROM
> code; but right now I can't do that and there's no guarantee I'll have
> debug info covering all of it anyway. So we're executing code way
> out in the boondocks. GDB doesn't have any way on this platform
> (ARM Thumb) to guess where the start of a function is if it doesn't
> have a symbol table; so it can't be sure that we've really reached the
> first instruction of a function, so it has no idea whether $lr is valid
> or not.

But that really means that we shouldn't be messing with step-resume
breakpoints here. The whole notion of functions that can be stepped
into isn't there.

Mark