On Tue, Mar 9, 2010 at 11:16 AM, Lassi Tuura <[email protected]> wrote:
>
> Yes, this is exactly what I was doing. I had GDB attached to the program,
> and whenever my program detected anomalous stack trace I made full libunwind
> stack dump, had GDB dump the same stack trace, and then manually inspected
> each of the anomalies: the address, the disassembly and readelf unwind
> dumps.
>
> The result was the five categories. I have not come across anything else
> yet in the hundreds of these I investigated. If you want the gory details I
> can post them.
>
I can comment about only two of the categories:
* f...@plt
src/x86_64/Gstep.c tries to deal with PLT. Perhaps there are bugs there?
* function + 0
This is caused by
static int
fetch_proc_info (struct dwarf_cursor *c, unw_word_t ip, int
need_unwind_info)
{
int ret, dynamic = 1;
--ip;
..
}
The --ip should be conditional based on whether it was a normal call/return
or not.
> Right, I think mine (SIGPROF) is of the first kind, i.e. saved %rip is
> where the execution will resume. What does libunwind assume for the "ip" of
> the dwarf cursor? Is it the instruction to be executed next, or already
> executed? Maybe I can knock up a patch for this.
>
>
libunwind picks up whatever is in the mcontext. Look for
UC_MCONTEXT_GREGS_RIP. As you say, this is unlikely to be your problem, but
something that needs to be fixed for correctness.
-Arun
_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel
