libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] Re: Backtrace from signal handler on arm from thre


From: Lassi Tuura
Subject: Re: [Libunwind-devel] Re: Backtrace from signal handler on arm from threads
Date: Thu, 3 Feb 2011 11:59:32 +0100

Hi,

> Copying over a libpthread with more symbols got even further.
> 
> Output without UNW_DEBUG_LEVEL: http://fpaste.org/c4yW/
> Output with UNW_DEBUG_LEVEL: http://folk.uio.no/hgb/outp2.1.gz
> 
> Note the new assertion that goes off.

Hm, it seems like you are passing past the end of stack (IP = 0):

  IP 0x403239b8, SP 0x40b8cfa0
  Loop for stack trace (15), cursor 0x40b884f8
  IP (nil), SP 0x40b8cfa0
  [assertion failure]

In src/dwarf/Gparser.c, apply_reg_state() does:

  /* DWARF spec says undefined return address location means end of stack. */
  if (DWARF_IS_NULL_LOC (c->loc[c->ret_addr_column]))
    c->ip = 0;

Then in src/x86_64/Gstep.c, unw_step() does:

  if (likely (ret >= 0))
    {
      /* x86_64 ABI specifies that end of call-chain is marked with a
         NULL RBP.  */
      if (DWARF_IS_NULL_LOC (c->dwarf.loc[RBP]))
         c->dwarf.ip = 0;
    }

The finally at the end of that function:

    ret = (c->dwarf.ip == 0) ? 0 : 1;
    Debug (2, "returning %d\n", ret);
    return ret;

It seems ARM side is missing some of those protections. Note that in your case 
you are likely in frame-chain code so the above Gparser.c code doesn't kick in, 
but the frame-chain code needs to simulate the result and from quick inspection 
I don't see that code in ARM's unw_step().

NB: You shouldn't have seen the IP=0 at all, the unw_step() which returned 
frame with IP=0x403239b8 should have returned with zero exit code to indicate 
end of stack, as it should have seen c->dwarf.ip == 0 at that point.

Regards,
Lassi


reply via email to

[Prev in Thread] Current Thread [Next in Thread]