On Tuesday 03 June 2014 09:53:02 Arun Sharma wrote:
> On Tue, Jun 3, 2014 at 6:18 AM, Milian Wolff <[email protected]> wrote:
> > To me that does not look like a failure :)
>
> Yeah, I'll fix up the test too unless this breaks any of the stuff
> Lassi may be aware of.
I just noticed an issue with adding the simple !bdp check to Gtrace.c - it
leads to an early cancellation of the backtraces when sections without debug
symbols are encountered:
...
0x7f868820167a QMapData::node_create(QMapData::Node**, int, int)
/usr/lib/libQtCore.so.4
0x7f86886ea740 ? /usr/lib/libkdecore.so.5
0x7f86886fa986 ? /usr/lib/libkdecore.so.5
0x7f86886fafc4 ? /usr/lib/libkdecore.so.5
0x7f86886e4320 ? /usr/lib/libkdecore.so.5
0x7f86886e4731 KConfig::KConfig(QString const&, QFlags<KConfig::OpenFlag>,
char const*) /usr/lib/libkdecore.so.5
... more useful information here
becomes
...
0x7f868820167a QMapData::node_create(QMapData::Node**, int, int)
/usr/lib/libQtCore.so.4
For my use-case this is unacceptable. Any idea what might be going on here?
Any information you would like me to get you?
> > Furthermore, while this patch fixes the unw_backtrace usage for me,
> > shouldn't the same be done for the unw_step case? There, the last call to
> > unw_step still triggers the slow-path which I mentioned in my original
> > thread. How could we fix this? Where is the analogous check for last
> > frame based on rbp in the code? And, if we'd fix it there, wouldn't then
> > the patch to Gtrace.c be obsolete, as then we'd get ret == 0 already, no?
>
> Here's the code that does the same thing in unw_step:
>
> src/x86_64/Gstep.c:
>
> if (!rbp)
> {
> /* Looks like we may have reached the end of the call-chain.
> */ rbp_loc = DWARF_NULL_LOC;
> rsp_loc = DWARF_NULL_LOC;
> rip_loc = DWARF_NULL_LOC;
> }
> ...
> if (DWARF_IS_NULL_LOC (c->dwarf.loc[RBP]))
> {
> ret = 0;
> Debug (2, "NULL %%rbp loc, returning %d\n", ret);
> return ret;
> }
>
>
> But anything can happen once you get into a weird combination of dwarf
> based unwinding, frame chain based unwinding, heuristics and real
> world complexity :)
The code here is already in libunwind, no? But why does it not "hit" in my
case? I.e. if unw_step would return 0, that should be chached properly by
unw_backtrace and the slow-path should not occur afterwards - or am I missing
something?
Bye
--
Milian Wolff
[email protected]
http://milianw.de
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
