On Monday 02 June 2014 10:01:02 Arun Sharma wrote: > On Mon, Jun 2, 2014 at 9:40 AM, Milian Wolff <[email protected]> wrote: > > So... what now? > > > >_ULx86_64_tdep_trace: frame va 400d28 type 0 last 0 cfa rsp+0 rbp @ cfa-1 > >rsp @ cfa-1 > > > >_ULx86_64_tdep_trace: new cfa 0x7fffb98a3820 rip 0x400d28 rsp > >0x7fffb98a3820 rbp 0x0 > It looks like the fast unwind path found RBP=0, but f->last_frame is > computed based on the return value of unw_step(). > Does this improve the situation? > > --- a/src/x86_64/Gtrace.c > +++ b/src/x86_64/Gtrace.c > @@ -254,7 +254,7 @@ trace_init_addr (unw_tdep_frame_t *f, > common for the outermost frame (CRT stuff) on many systems. > This avoids failing trace in very common circumstances; failing > to unw_step() loop wouldn't produce any better result. */ > - if (ret == 0) > + if ((ret == 0) || !rbp) > f->last_frame = -1;
Yes, that helps indeed. But I still have the frame above __libc_start_main in my backtraces. Is that "OK"? -- Milian Wolff [email protected] http://milianw.de _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
