gdb-6.5 produces infinite backtrace on ARM

Daniel Jacobowitz wrote:
> Oh, I see.  Interesting.  We'll see what we can do
about this; that
> does make more sense.
> 
> However, since it has obviously listed a bunch of
frames, CDT should
> not be discarding the ones that did succeed!
> 

The stack-list-frames command does not return any stack info
at all if
error(...) is called. Therefore CDT is not discarding
anything. The is
just the error message.

Regards
Olav

On Wed, Sep 06, 2006 at 05:37:59PM +0200, Zarges, Olav
wrote:
> 
> Daniel Jacobowitz wrote:
> > Oh, I see.  Interesting.  We'll see what we can
do about this; that
> > does make more sense.
> > 
> > However, since it has obviously listed a bunch of
frames, CDT should
> > not be discarding the ones that did succeed!
> > 
> 
> The stack-list-frames command does not return any stack
info at all if
> error(...) is called. Therefore CDT is not discarding
anything. The is
> just the error message.

Sorry - I misread your trace.  OK, I see what's generally
wrong...

-- 
Daniel Jacobowitz
CodeSourcery

Daniel Jacobowitz wrote:
>> The stack-list-frames command does not return any
stack info at all if
>> error(...) is called. Therefore CDT is not
discarding anything. The is
>> just the error message.
> 
> Sorry - I misread your trace.  OK, I see what's
generally wrong...

Glad to hear...

In order to supply other members of our dev-team with a
working gdb
I tried to apply the patch you published on

http://sourceware.org/ml/gdb-patches/2006-08/msg00131.
html

to the gdb-6.5-release I use. But the files did not match.
CVS-head didn't
work either. You probably have a revised version.

Then I just added my changes (warnings instead of errors)
and your new
frame_register_unwind_location() function and its invocation
to
gdb-6.5-release source tree. Gdb then crashes after hitting
the second
breakpoint.

It works if you patch your patch:

============================================================
=======
                                int *optimizedp, enum
lval_type *lvalp,
                                CORE_ADDR *addrp, int
*realnump)
{
-	while (this_frame->level >= 0)
+	while (this_frame != 0 && this_frame->level
>= 0)


Do you plan to publish a patch on top of gdb-6.5-release for
this issue?


-- 
Olav A. Zarges

On Thu, Sep 07, 2006 at 06:15:49PM +0200, Zarges, Olav
wrote:
> Then I just added my changes (warnings instead of
errors) and your new
> frame_register_unwind_location() function and its
invocation to
> gdb-6.5-release source tree. Gdb then crashes after
hitting the second
> breakpoint.

You can't do that.  Frames should never be NULL; having a
return
in a path which returns a NULL frame is invalid.

> Do you plan to publish a patch on top of
gdb-6.5-release for this issue?

Maybe, but probably not.  We don't have enough manpower for
that sort
of thing; I will try to get HEAD fixed, but that's all I
can promise.

-- 
Daniel Jacobowitz
CodeSourcery