User:Blauzahl/How to read backtraces

< User:Blauzahl
Revision as of 01:10, 3 April 2009 by Blauzahl (talk | contribs) (remove "cripes" line)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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 edited on 3 April 2009, at 01:10. Content is available under Creative Commons License SA 4.0 unless otherwise noted.