On Tue, Mar 9, 2010 at 11:16 AM, Lassi Tuura
<address@hidden> 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:
* address@hidden
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