Re: [libunwind] UNW_FLAG_INTERRUPT_FRAME

[David Mosberger]

Hi Troy,

>>>>> On Thu, 26 Aug 2004 11:11:01 -0600, Troy Heber <address@hidden> said:

  Troy> On 08/25/04, David Mosberger wrote:
  >> >>>>> On Wed, 25 Aug 2004 10:52:03 -0600, Troy Heber
  >> <address@hidden> said:

  Troy> I tried that, but unw_is_signal_frame seems to change
  Troy> something in the cursor state.
  >>  The suggests a bug in the accessor routines you're using.
  >> unw_is_signal_frame() doesn't change anything on its own.

  Troy> A touch more interesting information.

  Troy> I have a test case where exporting UNW_DEBUG_LEVEL=16 makes it
  Troy> stop unwinding on the correct frame, 3 from my previous
  Troy> example, and with UNW_DEBUG_LEVEL=0 it keeps going into frame
  Troy> 4!

  Troy> I'm using a bk pull from yesterday for my libunwind.

I'm afraid this will require some debugging.  I don't see anything
obvious wrong with your code (but then again, it's fairly big and I
only had time to took a quick look).  The effects you describe sure
sound like some memory corruption.  I suppose it's possible, though
not hugely likely that the problem is in libunwind.  I'd say it's more
likely that the memory corruption happens outside of libunwind.  Keep
in mind that some of the unwind data-structures are quite big (both
unw_cursor_t and unw_context_t are big).  Apart from that, you also need
to be careful about the lifetime of the data returned by find_proc_info().
Those are the only two obvious candidates that come to mind in regard
to memory corruption.

        --david