Unwinders -

Does this stack trace make sense to anybody?

#0 dwarf_get (c=0x7fffffffc8e0, c=0x7fffffffc8e0, val=0x7fffffffc808, loc=...)
    at ../include/tdep-x86_64/libunwind_i.h:164
#1  apply_reg_state (c=c@entry=0x7fffffffcec0, rs=rs@entry=0x7fffffffc8e0)
    at dwarf/Gparser.c:1147
#2 0x00007ffff79c288f in _Ux86_64_dwarf_find_save_locs (c=c@entry=0x7fffffffcec0)
    at dwarf/Gparser.c:1280
#3 0x00007ffff79c3ff9 in _Ux86_64_dwarf_step (c=c@entry=0x7fffffffcec0) at dwarf/Gstep.c:34
#4  0x00007ffff79baca1 in _Ux86_64_step (cursor=cursor@entry=0x7fffffffcec0)
    at x86_64/Gstep.c:71
#5  0x0000000000401684 in do_backtrace () at test-ptrace.c:134
#6 0x000000000040121e in main (argc=4, argv=0x7fffffffd408) at test-ptrace.c:309

It shows dwarf_get with 2 cursor arguments, not 1, and neither is the cursor argument passed to apply_reg_state. Also, it is the reason I'm failing a 'make check' case with a patch that changes the cache to match ip intervals, not particular ips. Two of these checks remain unresolved, and this one befuddles me.

The result, BTW, is that the bottom level cursor has a null as_arg field, so -UNW_EINVAL is returned.

If anybody knows what to make of this, I'd welcome the help.

Doug Moore



_______________________________________________
Libunwind-devel mailing list
Libunwind-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/libunwind-devel

Reply via email to