User:Blauzahl/How to read backtraces: Difference between revisions
(start of a bt explanation which is really going to turn into a list of sample bugs for triagers to look at) |
(remove "cripes" line) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
Sample bug report here: {{Bug|168987}} | Sample bug report here: {{Bug|168987}} | ||
| Line 18: | Line 17: | ||
Bz: do they often start with different functions? (is __assert_fail a fucntion?) | 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. | KHTMLGlobal::finalCheck () checks to make sure that things are OK when you're exiting program. | ||
Latest revision as of 01:10, 3 April 2009
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 :-)