User:Blauzahl/How to read backtraces: Difference between revisions

    From KDE TechBase
    (start of a bt explanation which is really going to turn into a list of sample bugs for triagers to look at)
     
    (ok, a touch clearer, still needs to be turned into real english)
    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?)
    <SadEagle> yes.
    SadE: yes.


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

    Revision as of 07:00, 14 August 2008

    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  :-)