Sorry for slow reply - unfortunately I haven't had much chance to look into this in detail.
The things that ideally should happen: - Dwarf unwinder should detect the "last" frame in the stack and stop there. IIRC this was supposed to be based on null return address column in the dwarf info, and there should be an "if" in the generic dwarf parsing to detect this. I don't recall how this was (if at all) recorded through frame stashing and fast trace though, and didn't have time to look into it in detail. - The frame stash should a) record the frame, b) remember somehow or another it's the last frame. - The fast trace should stop when at the end of the frame chain. I am not sure but I don't think Arun's suggested check on RBP would be the right thing to do, but I didn't fully trace how its value be would be tracked through the multi-condition "if". Maybe it's the right thing, just not sure. The main thing I would look at, using full libunwind debug levels, is how the very first pass through the last frame is parsed and handled. First make sure it is correctly parsed and detected as the last frame in the chain, and if that's not the case, maybe look into why either the dwarf frame info is incorrect, or why the heuristics don't correctly detect the case. If and only if that detection is correct, figure out why the fast trace gets it wrong, and falls off the fast path. We did run into several common enough cases where fast trace wouldn't detect the last frame correctly, and fell off to the slow trace, which would just produce the same result - slower. That was really annoying so you have my full sympathy :-) I tried to fix all the deficiencies we found, but certainly there can be more of them. I was hoping linux system libc would by now correctly annotate everything with dwarf, maybe it's just a matter of suitable configuration, compilation or linking flags somewhere? On Wed, Jun 4, 2014 at 7:01 PM, Milian Wolff <[email protected]> wrote: > On Wednesday 04 June 2014 15:45:52 Milian Wolff wrote: > > On Wednesday 04 June 2014 15:28:10 Milian Wolff wrote: > > > 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? > > > > Note: this patch seems to work just fine for me, but I don't know > whether it > > breaks anything else... At least the tests work just fine with it! So, do > > you see any other problems with it? > > Hm no that one is not enough apparently. It still triggers too many slow > paths > ending up in the initial bottleneck I found. > > Really, so far only the check for a null rip seems to work both fast and > reliable in my case... Any ideas on how to proceed now? > > Bye > -- > Milian Wolff > [email protected] > http://milianw.de >
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
