Does this stack trace make sense to anybody?
#0 dwarf_get (c=0x7fffffffc8e0, c=0x7fffffffc8e0, val=0x7fffffffc808,
#1 apply_reg_state (c=c@entry=0x7fffffffcec0, rs=rs@entry=0x7fffffffc8e0)
#2 0x00007ffff79c288f in _Ux86_64_dwarf_find_save_locs
#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)
#5 0x0000000000401684 in do_backtrace () at test-ptrace.c:134
#6 0x000000000040121e in main (argc=4, argv=0x7fffffffd408) at
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.
Libunwind-devel mailing list