#1 Interesting
by Racer
Monday April 19th, 2004 7:57 PM
Fun to see what crashes show up in the different versions...
In 1.6, the top crashers are (1) 64 gklayout.dll, (2) 34 js3250.dll, (3) 31 GKLAYOUT.DLL
while in 1.7b, its (1) 204 TableBackgroundPainter::TableBackgroundData::Destroy, (2) 104 nsJSContext::DOMBranchCallback, (3) 65 ntdll.dll
In the 1.7b build crash reports, there isn't even a mention of gklayout.dll - at good a sign that crashers are high priority.
#2 Re: Interesting
by bzbarsky
Monday April 19th, 2004 9:42 PM
Of course TableBackgroundPainter is part of gklayout.dll... I can't recall wheher DOMBranchCallback is too, but I think it is.
#3 Re: Re: Interesting
by Racer
Monday April 19th, 2004 10:02 PM
Ok then, forget what I said :p
#4 Re: Need help? Do it yourself
by lacostej
Monday April 19th, 2004 10:09 PM
Asa,
I see that the MTBF for the 1.7b build are pretty impressive (1.5 day). Do you have figures of the evolution of the mozilla MTBF in the past years?
I remember M4 to have an MTBF of 1.5 minute :)
J
#5 Re: Re: Need help? Do it yourself
by berkut
Tuesday April 20th, 2004 2:41 AM
http://www.acronymfinder.com/af-query.asp?p=dict&String=exact&Acronym=MTBF
#6 Re: Re: Need help? Do it yourself
by durbacher
Tuesday April 20th, 2004 5:55 AM
I have set up a page tracking MTBF data in January 2003 at http://www.stud.uni-karlsruhe.de/%7Eudex/mozilla-mtbf.html
However, you have to be very cautious when trying to get something out of it.
Many caveats are listed on the page and there are others.
One important point is that this data is only tracking trunk MTBF, not the one of releases. So it mainly tracks people who download nightlies to test them, often also to reproduce crash bugs. They tend to crash several times within a quarter of an hour or so to find out what's causing the crash - and this adds a MTBF of e.g. 2 Minutes several times to the database and surely gives no information about actual stability.
Another important point is that clients that never crash have no chance to report this successful running time (which could greatly increase MTBF). So displayed MTBF actually even can decrease with increasing stability!
Also note that the number of talkback reports varies greatly and is now much lower than before the long time without talkback. This may or may not mean that Mozilla is more stable now despite of quite low displayed MTBF, but it surely means that every single incident has much more of an impact on the results.
Maybe this page can be used to track MTBF within short intervals of time or large jumps of MTBF (e.g. after branches are cut). But that's about all it can.
#9 Re: Re: Re: Need help? Do it yourself
by durbacher
Wednesday April 21st, 2004 5:06 AM
> despite of quite low displayed MTBF
Actually, today trunk MTBF rose to 22 hours, much better than ever, doubled compared to yesterday, after having been only about 1 hour just four days ago (and half an hour six days ago).
What does that mean? About four crash bugs were fixed during the last four days, bug 240748, bug 240798 and bug 240997 existing only since a few days ago (FTP upload fallout). This could mean the low MTBF was only a temporary problem and Mozilla generally is in a much better shape than last September, even during alpha phase.
But I said the numbers are not reliable and let's not forget this when the numbers look great! <br>Raw data in crash-history.txt (linked on top of http://www.stud.uni-karlsruhe.de/%7Eudex/mozilla-mtbf.html) shows that the number of users crashing yesterday was similar to that four days ago, BUT the "testing time" is now multiplied by about 20!!
This can mean yesterday even people crashed who did not crash for a long time before. So there might be some evil crashers introduced and the MTBF of 22 hours a quite bad thing.
This can also mean BugDay caused people to reproduce crashes and only this way crashing at all after a long time without crashes. This would basically make the MTBF change meaningless, but is not too likely (the total testing time already went up before).
Or talkback is still not that reliable...
So what's the point of this posting? To show even to the unbelievers that the MTBF displayed does not really say much about product stability. Better trust your own experience!
#7 Reply
by napolj2
Tuesday April 20th, 2004 6:29 AM
Does the Mozilla Foundation have to pay some sort of fee to use QFA/Talback? Also, how long is the delay between submitting a talback report and when it is available with this public tool? Earlier I had to wait about a week before one of my talkbacks was listed.
#8 Tables
by WillyWonka
Tuesday April 20th, 2004 7:13 AM
I like the new interface. When it first went up I didn't realize that it was 2 different forms.
Looks like the Table programmers have their work cut out for them :)
#10 The tracker service crashed
by losttoy
Wednesday June 29th, 2005 8:48 AM
Looks like the talkback service itself crashed
http://talkback-public.mozilla.org/talkback/fastfind.jsp
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
org.apache.jasper.JasperException
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
root cause
java.lang.NullPointerException
org.apache.jsp.fastfind_jsp._jspService(fastfind_jsp.java:245)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
| 
Quality Feeback Agent (Talkback) Crash Reports Available for Public Viewing