Re: [PATCH 1/2] avoid infinite loop with bad debuginfo

[Pedro Alves <palves at redhat dot com>]

On 11/19/2013 06:06 PM, Tom Tromey wrote:
> It seems to me that the loop in question could perhaps be reached from
> some path outside the unwinder.  

Yes, that's actually what my example was about.  I was assuming the
recursion fixed already.

> If so, bad DWARF would be able to cause
> an internal error -- clearly incorrect.  

I don't think so, because get_prev_frame_1 would not link in
the dup frame.  The loop in question would never see it.

Hmm, I think one of us is missing something.

      while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val))
	{
	  frame = frame_find_by_id (VALUE_FRAME_ID (new_val));
...
	  new_val = get_frame_register_value (frame, regnum);
	}

get_frame_register_value unwinds the value in question from the
next frame.

struct value *
get_frame_register_value (struct frame_info *frame, int regnum)
{
  return frame_unwind_register_value (frame->next, regnum);
                                      ^^^^^^^^^^^
}

IOW, if we get a lazy lval_register, it should have
the frame ID of the _next_ frame, never of FRAME.

At this point, the whole relevant chunk of the stack has
already been unwound -- note the loop always "unlazies"
lval_registers in the "next/innermost" direction, not in
the "prev/unwind further/outermost" direction.

So the bad loop can only ever happen (outside the unwinder code)
if we ever let outselves get in the dup frame_id situation:

>     #4  0x0000007fb7f0956c in clone () from /lib64/libc.so.6
>     #5  0x0000007fb7f0956c in clone () from /lib64/libc.so.6
>     Backtrace stopped: previous frame identical to this frame (corrupt stack?)

At least, I'm not seeing any other way.

-- 
Pedro Alves