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
