That's expected. For eg these unit tests do it too: ./tests/Ltest-bt v ./tests/Ltest-trace v
do it too. -Arun On Mon, Jun 2, 2014 at 11:41 AM, Milian Wolff <[email protected]> wrote: > 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
