User:Blauzahl/How to read backtraces

Jump to: navigation, search

Sample bug report here: bug #168987

If reporter says they didn't close their browser, it isn't a dup. Qt crashed.

SE says: BTW, as seen on that bug report, KHTMLGlobal::finalCheck and other cleanups get called on an assert-failure. Not sure it's fixable, but it is wrong, and often confuses the triagers

I wanted to know why and what we were supposed to look for:


The report has the abort from __assert_fail from KHTMLGlobal::finalCheck () that often happens on exit crashes.

Often, people want to merge this to an exit crash report... But if you look below, you'll see that in line 19 it already aborted. (Qt quits in lines 16-19, line 19 is the actual abort.)


below here won't make sense, likely

Bz: do they often start with different functions? (is __assert_fail a fucntion?) SadE: yes.

SE: KHTMLGlobal::finalCheck () checks to make sure that things are OK when you're exiting program.

But sometimes it gets called when the application has already crashed, and then it aborts the application again going "stuff shouldn't look like this at a normal exit!" And, well, it doesn't, since it's a normal exit.

<blauzahl> you mean lines 16-19 where it looks like qt exits? 19 is the actual abort? <SadEagle> Actually, in this case it's probably a problem with qt_assert that dfaure fixed --- but shouldn't that be in 4.4.0 already? <SadEagle> Yeah. <SadEagle> and the easiest way to tell that abort is if the report doesn't mention exitting/closing the browser  :-)


This page was last modified on 3 April 2009, at 02:10. This page has been accessed 1,000 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal