crasher in dwarf2loc.c

crasher in dwarf2loc.c

[Michael Snyder]

Hey Daniel, 

I've got a core dump coming from dwarf_expr_frame_base.
First you call get_frame_function, and then you immediately
use its return value.  But get_frame_function can return zero, 
so I think you need to check for zero before using it.

Michael

PS: more details:  get_frame_block returns zero, because
frame_address_in_block returns a pc that is not in any block.

The crash occurs while running recurse.exp, when we have a
watchpoint on a local variable in an inner frame, and we 
continue -- so I don't know the exact context; but I'm 
willing to bet that it is trying to evaluate the local
variable after the stack frame has been destroyed.

Re: crasher in dwarf2loc.c

[Daniel Jacobowitz]

On Tue, Apr 22, 2003 at 05:50:56PM -0700, Michael Snyder wrote:
> Hey Daniel, 
> 
> I've got a core dump coming from dwarf_expr_frame_base.
> First you call get_frame_function, and then you immediately
> use its return value.  But get_frame_function can return zero, 
> so I think you need to check for zero before using it.
> 
> Michael

Just to avoid the crash, you're probably right.

> PS: more details:  get_frame_block returns zero, because
> frame_address_in_block returns a pc that is not in any block.
> 
> The crash occurs while running recurse.exp, when we have a
> watchpoint on a local variable in an inner frame, and we 
> continue -- so I don't know the exact context; but I'm 
> willing to bet that it is trying to evaluate the local
> variable after the stack frame has been destroyed.

Huh - we should not even be reaching this code.  I don't quite
understand your explanation; what target does this happen?  Can it be
reproduced on a simulator, or something of that ilk?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: crasher in dwarf2loc.c

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Tue, Apr 22, 2003 at 05:50:56PM -0700, Michael Snyder wrote:
> > Hey Daniel,
> >
> > I've got a core dump coming from dwarf_expr_frame_base.
> > First you call get_frame_function, and then you immediately
> > use its return value.  But get_frame_function can return zero,
> > so I think you need to check for zero before using it.
> >
> > Michael
> 
> Just to avoid the crash, you're probably right.
> 
> > PS: more details:  get_frame_block returns zero, because
> > frame_address_in_block returns a pc that is not in any block.
> >
> > The crash occurs while running recurse.exp, when we have a
> > watchpoint on a local variable in an inner frame, and we
> > continue -- so I don't know the exact context; but I'm
> > willing to bet that it is trying to evaluate the local
> > variable after the stack frame has been destroyed.
> 
> Huh - we should not even be reaching this code.  I don't quite
> understand your explanation; what target does this happen?  Can it be
> reproduced on a simulator, or something of that ilk?

mumble, mumble...

[...]

mumble, mumble, mumble...

OK, yes.

But first you have to back out this change: then run recurse.exp.
If it doesn't crash in your target of choice, try h8300-elf (sim).

2003-04-21  Andrew Cagney  <cagney@redhat.com>

	* frame.c (frame_id_eq): Fail when the code_addr's do not match.

*************** frame_id_eq (struct frame_id l, struct f
*** 295,304 ****
      /* The .stack and .code are identical, the ID's are identical.  */
      eq = 1;
    else
!     /* FIXME: cagney/2003-04-06: This should be zero.  Can't yet do
!        this because most frame ID's are not being initialized
!        correctly.  */
!     eq = 1;
    if (frame_debug)
      {
        fprintf_unfiltered (gdb_stdlog, "{ frame_id_eq (l=");
--- 295,302 ----
      /* The .stack and .code are identical, the ID's are identical.  */
      eq = 1;
    else
!     /* No luck.  */
!     eq = 0;
    if (frame_debug)
      {
        fprintf_unfiltered (gdb_stdlog, "{ frame_id_eq (l=");

Re: crasher in dwarf2loc.c

[Daniel Jacobowitz]

On Thu, Apr 24, 2003 at 05:18:39PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Tue, Apr 22, 2003 at 05:50:56PM -0700, Michael Snyder wrote:
> > > Hey Daniel,
> > >
> > > I've got a core dump coming from dwarf_expr_frame_base.
> > > First you call get_frame_function, and then you immediately
> > > use its return value.  But get_frame_function can return zero,
> > > so I think you need to check for zero before using it.
> > >
> > > Michael
> > 
> > Just to avoid the crash, you're probably right.
> > 
> > > PS: more details:  get_frame_block returns zero, because
> > > frame_address_in_block returns a pc that is not in any block.
> > >
> > > The crash occurs while running recurse.exp, when we have a
> > > watchpoint on a local variable in an inner frame, and we
> > > continue -- so I don't know the exact context; but I'm
> > > willing to bet that it is trying to evaluate the local
> > > variable after the stack frame has been destroyed.
> > 
> > Huh - we should not even be reaching this code.  I don't quite
> > understand your explanation; what target does this happen?  Can it be
> > reproduced on a simulator, or something of that ilk?
> 
> mumble, mumble...
> 
> [...]
> 
> mumble, mumble, mumble...
> 
> OK, yes.
> 
> But first you have to back out this change: then run recurse.exp.
> If it doesn't crash in your target of choice, try h8300-elf (sim).

Cleaning, cleaning...

Michael, FYI, I'm going to consider this problem moot unless you manage
to reproduce it in the current sources; I can't.  With Andrew's change
it shouldn't happen.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer