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.
cripes... yes to which one?
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 :-)