Firefox 5: summary of problems reported on support forums/Twitter
Teoli
Now, about 10 days after the launch of Firefox 5, I would like to share
with you some observations I made from wandering on different support
forums.
The launch of Firefox 5 has one important difference from the previous
launches. It was an almost-immediate, mandatory update.
Previously, lots of people migrated only when the X.Y.2 ou X.Y.3 was
out. An important part of the early problems of the new release were
therefore not felt by the least computer-savvy Firefox users, especially
extensions compatibility problems. As it is not the case with this
latest migration, it let us see different problems. I list them in the
order of occurrence.
1) Most reported problems are with incompatible extensions.
- The Google Toolbar
Most people use it to manage their bookmarks (and for non-english users
to translate a webpage), but I noticed that :
a) Some people don't know that they are using an extension. They believe
that the Google Toolbar is a genuine part of Firefox.
People don't know that their bookmarks are then stored outside their
computer. They don't understand dataloss risks, privacy- and law-related
consequences of doing this.
b) Most people use it for nothing more than what Firefox' Bookmarks
Manager can do. Especially very few are using it to be able to see their
bookmarks via the iGoogle website. They didn't discover the Bookmarks
Manager features.
c) People are angry when loosing bookmarks. (Like when loosing any other
data, being passwords, open tabs, form content...)
d) The most funny reason to use the Google Toolbar I found was by one
guy in Canada who was using it in order to be able to do searches...
with Google ! His Firefox didn't allow him to do this. After digging a
bit, I discovered that he was using a Firefox with the Yahoo Toolbar
installed (without him doing it on purpose) ; this changed long ago the
default search engine of Firefox and as he didn't discovered the feature
of Manage Search Engines... the only way to search the web using Google
he found was to install the toolbar (or to go to the website which takes
more time). Once he discovered the way to manage his search engines, he
stopped using both toolbars.
- The AV-related extensions
a) People are scared when an extension containing the name of the AV or
security suite is said to be incompatible. Even if they don't use it,
they believe to be insecure. Some even believe that their whole security
suite will be disabled on their computer when upgrading Firefox.
b) AV-related extensions brings two features that a lot of their users
are using nowadays:
- Password managers (when missing they loose their passwords)
- Virtual keyboards to prevent � easy keylogging �
c) A few others that are incompatible, but nothing special about them.
2) Crashes
On Twitter, where people are more likely to say � I switched away from
Firefox because... �, the first reason of doing this is _crashes_.
Usually these people are experiencing several crashes/hour (I would say
at least 20 crashes/day).
A few join a forum to get help, but no clear pattern is appearing : some
have bad pilots (disabling GPU-acceleration helps), some have bad
combination of extensions/plugins (a new profile, w/o most of the
plugins helps), some cannot be helped at all (Firefox bug?, but no real
STR). This is a problem that seems to have grown bigger since Firefox 4
and wasn't cured by Firefox 5.
On Twitter a few people report crashes because they reach the 2 GB
memory limit (on Windows), with about 60 tabs.
3) Response time
Always on Twitter, the second reason of switching away, is speed. The
term is very imprecise and may represent several different things but I
saw reports of :
- people having to wait about 4 seconds each time they switch a tab
(usually some _random_ extension is the cause of this)
- people having the whole browser periodically freezing (it looks that
this maybe memory-pressure related, but w/o certainty).
Beside this, there is also a lot of positive feedback (much quicker,
less crashy!). And also reports of people migrating from others browsers
(even Chrome) to Firefox because of its stability.
These are some observations I did watching support forums and Twitter.
On purpose, I tried to be only descriptive. Note that these are not the
observations drawn out of formal measurement (metrics); but I do believe
that feelings are also important as formal metrics are not always perfect.
Hope it may help you and sorry for the long post.
--
Jean-Yves Perrier
Benoit Jacob
>
> On Twitter, where people are more likely to say « I switched away from
> Firefox because... », the first reason of doing this is _crashes_. Usually
> these people are experiencing several crashes/hour (I would say at least 20
> crashes/day).
>
> A few join a forum to get help, but no clear pattern is appearing : some
> have bad pilots (disabling GPU-acceleration helps), some have bad
> combination of extensions/plugins (a new profile, w/o most of the plugins
> helps), some cannot be helped at all (Firefox bug?, but no real STR). This
> is a problem that seems to have grown bigger since Firefox 4 and wasn't
> cured by Firefox 5.
>
> On Twitter a few people report crashes because they reach the 2 GB memory
> limit (on Windows), with about 60 tabs.
Regarding crashes, we have hard data, which is probably more reliable
than whatever can be obtained by reading twitter comments:
https://crash-stats.mozilla.com
Here's the list of top firefox 5 crashers:
https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/5.0/7
It says that major causes of crashes are JS engine bugs, and malware
on users' systems. It really doesn't say that GPU-acceleration is such
a big cause of crashes. However, there is room for improvement on the
front of stability with regard to GPU acceleration, and the most
important bug to fix in this area is probably
https://bugzilla.mozilla.org/show_bug.cgi?id=628129
>
> 3) Response time
Regarding response time, I believe that Telemetry, introduced in
Firefox 7, will provide the hard data that's needed to make the most
progress.
Cheers,
Benoit
Jesper Kristensen
> Regarding crashes, we have hard data, which is probably more reliable
> than whatever can be obtained by reading twitter comments:
>
> https://crash-stats.mozilla.com
>
> Here's the list of top firefox 5 crashers:
>
> https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/5.0/7
>
> It says that major causes of crashes are JS engine bugs, and malware
> on users' systems. It really doesn't say that GPU-acceleration is such
> a big cause of crashes. However, there is room for improvement on the
> front of stability with regard to GPU acceleration, and the most
> important bug to fix in this area is probably
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=628129
I don't think these topcrashes is a very good reflection of perceived
crashiness. Maybe you could make such a list which only counts crashes
from users who crash more than x times per day. I think that would
better reflect the most painful crashes.
>
>>
>> 3) Response time
>
> Regarding response time, I believe that Telemetry, introduced in
> Firefox 7, will provide the hard data that's needed to make the most
> progress.
I think all of the points made by Teoli would be a good focus area for
Telemetry, since we hear about them frequently in support.
How many users had their extensions disabled by an update? How many of
the users running an outdated version of Firefox would have extensions
disabled if they upgraded? Which extensions? What is the crash history
of the people with hardware acceleration disabled? Which GPU drivers do
they have?
-
Jesper
RamonS
functionality introduced by FF4 did not get addressed. From what I
collected over the past months these are the most common complaints:
1) insane use of memory - still an issue and quite obvious when
viewing the same web page using FF and any other browser. The other
browser, regardless which one, has always a noticeably smaller memory
foot print.
2) switch to tab feature is utterly annoying - There was no need to
introduce this. It is one example where apparently a group of
developers made a feature decision causing worse UX. Some may like it,
so keep it, but disable it by default. Besides that, there are bugs to
fix that are more pressing than adding features of little to no use. I
heard the argument (typically worded as an insult): Why the heck would
one want to open more than one tab with the same web page? One example
is the comparison of map data between proprietary maps and public
maps, especially in regards to determining accurate lat/lon
coordinates. And yes, for that task one needs to open Google Maps five
or more times in different tabs. And in neither of these tabs the same
content is displayed! With an ever more dynamic web the fact that URLs
are the same is no basis to make a decision of a page being the same.
3) open link in new tab does not work within secondary window - I
agree, that is my personal pet peeve. I make use of tickers
extensively, which often show in secondary windows that are sized
appropriately. Opening a link from the ticker in a new tab will
display a page that is optimized for the window size. I know the
thread that discusses this and that thread gives the impression as
that this 'feature' got sold as better UX when in fact it is exactly
the opposite.
4) buttons are too small by default - Although I loathe the gelled
look of the modern browsers I guess some go for that no UI approach.
But with screen resolutions going up why are buttons made smaller?
Especially when the newest fad is touch screens. Who can easily
operate a microscopic button that is even difficult to click with a
mouse pointer? This refers mainly to the Firefox button in the new
default UI.
5) back/forward history present does not clearly color arrows in
applicable buttons - when the buttons have a browse history attached
the arrow glyphs only faintly change to a slightly different shade of
gray. That together with the removal of the indicators (present in
FF3) give the illusion as that backward / forward browse history is no
longer available. The right-click to get the list is very unintuitive
as there is nothing indicating that right-clicking is a worthwhile
action to perform.
6) startup and overall performance could be better - Here I see the
biggest work to be done in startup. Compared to other browsers and
other applications in general it takes ages for FF to even show up.
7) Versioning - much discussed and clearly just a marketing decision
to catch up to Google's ridiculous versioning. Honestly, FF5 is
nothing more than a dot release to FF4 and nobody cries foul when new
features are introduced in a dot release. Go back to the approach used
before. There is no value in inflating major release version
numbers.It only spells trouble with extensions not catching up and
with users clinging to older versions that then no longer get security
updates.I think that users rather wait some time for a bunch of new
features that they currently do without than to constantly have to
find ways of reinstating existing functionality that gets lost with
new versions, either because FF dropped the feature or the extensions
no longer work.I'm not even talking about enterprise users here.
8) Dependence on Windows Internet Settings - not new to recent
releases and with some good reasoning behind it, but with bad
implementation. Should have kept individual settings with an option to
align them with the IE settings. Many use different browsers based on
task, because some browsers are better suited for task A than task B.
Having no means of setting the overall configuration individually is a
disadvantage.
9) Inability to uninstall extensions /add-ons at times - biggest
offender here is Java. On some systems it can only be disabled while
other systems using the exact same FF build allow for an uninstall.
Not sure what the reasons are, but regardless of where the add-on /
extension (by the way, nobody gets the difference, so call them by the
same name) came from FF should allow to uninstall it entirely.
I do appreciate the efforts to collect more usage stats as this is
more reliable data than complaints from disgruntled FF users like
myself who loved FF3 and now basically hate FF4/5. Nevertheless, FF is
suffering from much bigger problems (mainly memory consumption and
performance) that should have been fixed instead of needlessly
reducing the UI to nothing and causing worse user experience. Google
has an OK browser in Chrome (I don't like it due to lack of a UI), but
FF carved out its niche and has strengths (extensions, ease of use in
FF3 and below, Mozilla has much better reputation than Apple, Google
or Microsoft). Fixing stability, performance, and memory issues as
well as adding full standard compliant support for HTML5 are the areas
to work on. Not the UI! There was absolutely nothing wrong with the UI
in FF3. Anyone could use the FF3 UI, can't say that for FF4 and up.
Lastly, I think the focus of the development team needs to be adjusted
a bit to get away from cloning Chrome. If users think Chrome is better
they will use it anyway. Then again, what should be copied from Chrome
is the excellent performance. Focus on that rather than adding more
doohickeys like PDF readers or moronic ideas like killing the address
bar. In fact, I am convinced that rolling back to the FF3 UI will make
more people happy.
What might also prevent public blunders is to be more upfront about
the results of decision making. I've asked several times why something
changed this or that way and all I get is a link to a thread in
bugzilla that will be misunderstood by laymen. Example: the 'switch to
tab' feature was advertised on the welcome screens of FF, but no
reason given why this was added, why it is an advantage, and why it
makes my life easier. Three reasons in bullet points sell such a
feature, even if it is utterly useless and makes life miserable as in
this case. A few excellent reasons given will make arguing against any
change more difficult, but it will generate better responses. Besides
that, there is no clear path for users to give their input. The Submit
Feedback... option is a nice start, but after submitting feedback
there is no tracking of what happens with it. Given how FF shapes up
these days at least all my feedback was ignored. Which is why I feel
that it is necessary to hijack posts here and make people read my
lengthy comments. I still believe that Mozilla and the community make
FF for the greater good and for people to use it, although I get the
impression that more and more FF is made by developers who like to do
what developers like to do regardless if the users agree or not.
Thanks for reading,
David
Chris Ilias
> Now, about 10 days after the launch of Firefox 5, I would like to share
> with you some observations I made from wandering on different support
> forums.
Hi Teoli,
Thanks for taking the time to gather the info and report it. There's a
mailing list at <https://mail.mozilla.org/listinfo/sumo-report> for
reporting common issues. Maybe you could contact the list-owners to
integrate your info, or see what else you can do to help. Thanks again!
Jean-Marc Desperrier
> I don't think these topcrashes is a very good reflection of perceived
> crashiness. Maybe you could make such a list which only counts crashes
> from users who crash more than x times per day.
Yes, definitively. A crash that affect a million users but only once
every year will generate more stacktraces than one that crash every
single day only one user in a million. But the second one will be a lot
more painful.
And some of the GPU-acceleration bugs belong to the second category. It
used to work well but suddenly it becomes very crashy.
Robert Kaiser
> I don't think these topcrashes is a very good reflection of perceived
> crashiness. Maybe you could make such a list which only counts crashes
> from users who crash more than x times per day. I think that would
> better reflect the most painful crashes.
Feel free to propose actual algorithms we can run on a day-by-day basis
on the data we have that make the pain you think is there better
visible. Or maybe even better, work on fixes for crashes.
Meanwhile, we will use our known-to-be-imperfect analysis and try to get
developers to fix the crashes we see happening with high amounts of
cases, as we have lots of those to work on, unfortunately.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
Johnathan Nightingale
> Jesper Kristensen schrieb:
>> I don't think these topcrashes is a very good reflection of perceived
>> crashiness. Maybe you could make such a list which only counts crashes
>> from users who crash more than x times per day. I think that would
>> better reflect the most painful crashes.
>
> Feel free to propose actual algorithms we can run on a day-by-day basis
> on the data we have that make the pain you think is there better
> visible. Or maybe even better, work on fixes for crashes.
> Meanwhile, we will use our known-to-be-imperfect analysis and try to get
> developers to fix the crashes we see happening with high amounts of
> cases, as we have lots of those to work on, unfortunately.
Exactly this. Overall crash count is, to be sure, a proxy for pain not a
direct measurement of it, but it's the best proxy we have until someone
builds something better, and I think it's been a good guide for us so
far. I feel confident that Robert and the crashkill team would be happy
to help someone trying to build a better ranking algorithm, but I
support Robert's assertion that, for the most part, our time is best
spent taking down popular crashes by any metric.
J
Mike Shaver
<moznew...@something.to.remove.jesperkristensen.dk> wrote:
> I don't think these topcrashes is a very good reflection of perceived
> crashiness.
Which of our crashes do you feel contribute most to perceived crashiness? Why?
> Maybe you could make such a list which only counts crashes from
> users who crash more than x times per day. I think that would better reflect
> the most painful crashes.
Or it would identify a small number of users who have screwed up
systems, dodgy software jammed into their OS, or are otherwise
anomalous.
It's also very difficult to do without assigning each Firefox
installation a unique identifier, and correlating user reports on that
basis. This means that if you put your email address in one crash on
Wikipedia, but decide to omit it on the pornography site of your
choosing, you're effectively submitting it in the latter case too.
Mike
Jesper Kristensen
> On Sun, Jul 3, 2011 at 10:34 AM, Jesper Kristensen
> <moznew...@something.to.remove.jesperkristensen.dk> wrote:
>> I don't think these topcrashes is a very good reflection of perceived
>> crashiness.
>
> Which of our crashes do you feel contribute most to perceived crashiness? Why?
Like Jean-Marc said: "Yes, definitively. A crash that affect a million
users but only once every year will generate more stacktraces than one
that crash every single day only one user in a million. But the second
one will be a lot more painful."
>> Maybe you could make such a list which only counts crashes from
>> users who crash more than x times per day. I think that would better reflect
>> the most painful crashes.
>
> Or it would identify a small number of users who have screwed up
> systems, dodgy software jammed into their OS, or are otherwise
> anomalous.
Well, that is the unfortunate thing about the crash database. For a code
bug in Firefox I can make up a patch, build with it and try it out to
see if it works. With crash stats, I could come up with a query, but I
have no way of testing it out on the actual database.
And even if screwed up systems and the like populates the majority of
this list, that could still be a useful result. Mozilla has done a lot
to lock down Firefox to prevent failures of other programs from
affecting Firefox. If such failures would still turn up as frequent
crashers for a lot of users, maybe more could be done on that front.
>
> It's also very difficult to do without assigning each Firefox
> installation a unique identifier, and correlating user reports on that
> basis. This means that if you put your email address in one crash on
> Wikipedia, but decide to omit it on the pornography site of your
> choosing, you're effectively submitting it in the latter case too.
Again, I cannot try out a query on the crash database, but I would guess
that time since previous crash could be an indicator.
Den 07-07-2011 16:47, Robert Kaiser skrev:
> Feel free to propose actual algorithms we can run on a day-by-day basis on the data we have that make the pain you think is there better visible.
In pseudo sql language:
select * from crashes where �time since previous crash� < x group by
signature order by count(*)
> Or maybe even better, work on fixes for crashes.
Yes, but first it would be good to know which are the most important,
and what I am trying to say is that maybe there would be better ways of
measuring that. Again I don't know, as I cannot try out alternative
queries on the crash database.
Bill Barry
> It's also very difficult to do without assigning each Firefox
> installation a unique identifier, and correlating user reports on that
> basis. This means that if you put your email address in one crash on
> Wikipedia, but decide to omit it on the pornography site of your
> choosing, you're effectively submitting it in the latter case too.
I'd be fine with this as an opt-in somewhere. Perhaps 2 settings, one
checkbox somewhere to say "send Firefox installation Identifier on
crashes (this will uniquely identify this copy of Firefox to Mozilla and
anyone who looks at user reports)" and a second one in the report dialog
to enable/disable sending the id in the report they are sending at the time.
I am confident that there is already identifying information in a
significant number of reports. With a few false positives you probably
could datamine the reports and find sets from the same individual:
1. create a database of "words" in crash reports (words = one or more
non-whitespace characters consecutively, starting at a word boundry and
ending at one. trim punctuation from the end)
2. ignore anything that looks like a url or is a word from a dictionary
(the dictionary may be grown from the reports themselves in a number of
ways*)
3. get the set of reports which share a word in common
* given 2 reports which have a word in common, if the build identifier
is newer on the older report then the word likely is not usable as an
identifier for the firefox installation (as a user is unlikely to
install an older build on top of an existing installation).
Christian Legnitto
FWIW we think we found most of the causes of "Frankenfoxes" (mismatched exes and dlls / partial installs) a couple of updates ago (also fixed in 5+). Those users were likely extremely crashy compared to the rest of the population.
Thanks,
Christian
Chris Hofmann
>
> Again, I cannot try out a query on the crash database, but I would
> guess that time since previous crash could be an indicator.
>
> Den 07-07-2011 16:47, Robert Kaiser skrev:
>> Feel free to propose actual algorithms we can run on a day-by-day
>> basis on the data we have that make the pain you think is there
>> better visible.
>
> In pseudo sql language:
>
> select * from crashes where �time since previous crash� < x group by
> signature order by count(*)
>
>> Or maybe even better, work on fixes for crashes.
>
> Yes, but first it would be good to know which are the most important,
> and what I am trying to say is that maybe there would be better ways
> of measuring that. Again I don't know, as I cannot try out alternative
> queries on the crash database.
>
You can't run SQL queries directly on database, and you probably will
just have some exhaustive queries time out on the crash-stats web
interface, but you can do some interesting analysis of crashes using the
crash summary text files that get generated every day.
These crash summary text files have a lot of the meta data that you need
to do interesting correlations and connection of data that might surface
some patterns that can be analyzed further. These are the files that we
use a lot for developing experimental reports that eventually can be
added to crash-stats.m.o to help analysis.
You can grab those daily text files like 20110706-pub-crashdata.csv.gz
<https://crash-analysis.mozilla.com/crash_analysis/20110706/20110706-pub-crashdata.csv.gz>
from https://crash-analysis.mozilla.com/crash_analysis/20110706/ to
play around with experimental reports that you would like to see. If
you find something interesting that we should be looking at on a regular
basis file a bug under webtools | socorro and cc kairo and me.
some simple unix text file processing tools would give the answers to
the question you proposed above... (what does the top crash list look
like for the collection of crashes that have a low time since last crash
value? and does it differ from from the the norm?)
here is the top crash list, and crash counts, for signatures on firefox
5 where crashes have a time since last crash less than 60 seconds.
850 send
439 (no signature)
306 RtlpWorkerCallout
168 RtlpTpWorkCallback
150 arena_dalloc_small | arena_dalloc | free | CloseDir
122 js::mjit::EnterMethodJIT(JSContext*, JSStackFrame*, void*, js::Value*)
115 XPCWrappedNative::GetNewOrUsed(XPCCallContext&, xpcObjectHelper&,
XPCWrappedNativeScope*, XPCNativeInterface*, int, XPCWrappedNative**)
107 vksaver.dll@0x3d66
78 BaseThreadStart
77 js_XDRScript(JSXDRState*, JSScript**)
72 __RtlUserThreadStart
71 WSARecv
69 _PR_MD_SEND
61 PR_Write
59 memmove | nsCacheMetaData::SetElement(char const*, char const*)
59 NS_AccumulateFastLoadChecksum(unsigned int*, unsigned char const*,
unsigned int, int)
58 @0x1a2710
57 nsFrameList::RemoveFrame(nsIFrame*)
57 js::gc::MarkObject
57 js::Interpret(JSContext*, JSStackFrame*, unsigned int, JSInterpMode)
awk -F\t '$6 < 60 && $8 ~ /5.0/ {print $1}'
20110706-pub-crash-data.csv | sort | uniq -c | sort -nr | head -20
-chofmann
Robert Strong
wouldn't crash due to firefox.exe main purpose being to load xul.dll.
Bugs to get crash data to evaluate the affect of client changes
https://bugzilla.mozilla.org/show_bug.cgi?id=666065- after updater changes
https://bugzilla.mozilla.org/show_bug.cgi?id=635834 - before updater changes
Bugs that implemented client side changes to lessen mismatched dll's
https://bugzilla.mozilla.org/show_bug.cgi?id=525390
https://bugzilla.mozilla.org/show_bug.cgi?id=635161
--
Cheers,
Robert Strong
Robert Kaiser
> here is the top crash list, and crash counts, for signatures on firefox
> 5 where crashes have a time since last crash less than 60 seconds.
Just off the top of my head, without looking at details for each
signature, I think most of the high-ranking ones there are
malware-related, just as I expected. From all I know, we could remove a
vast majority of our crashes if we would refuse to load any binary code
other than our own. That would get rid of practically all malware- and
adware-related crashes, but also of all "avtivirus" tools tinkering with
our actions and a lot of add-ons, possibly/probably also of plugins (but
we could still allow NPAPI loading binaries).
I don't think that would be feasible, but it would reduce the crashes
Jesper seems to be worried about, and also most other startup crashes
(that "query" for fast-repeated crashes favors startup crashes being the
vast majority).
What I'm trying to say is that we know those are annoying and bad, but
they're really hard to fix, unless we build anti-malware/adware
technology into Firefox or kill a lot of useful extensibility, and I
don't think we want to do either. Still, any steps towards real
solutions that don't require those would be cool.
Mike Shaver
> I don't think that would be feasible, but it would reduce the crashes Jesper
> seems to be worried about, and also most other startup crashes (that "query"
> for fast-repeated crashes favors startup crashes being the vast majority).
> What I'm trying to say is that we know those are annoying and bad, but
> they're really hard to fix, unless we build anti-malware/adware technology
> into Firefox or kill a lot of useful extensibility, and I don't think we
> want to do either. Still, any steps towards real solutions that don't
> require those would be cool.
It might not be feasible as a default, but if we could make it an
optional mode then we could offer it via support or on about:crashes
or in the crash reporter, or heuristically as an info bar, etc.
Mike
Jesper Kristensen
> Just off the top of my head, without looking at details for each
> signature, I think most of the high-ranking ones there are
> malware-related, just as I expected. From all I know, we could remove a
> vast majority of our crashes if we would refuse to load any binary code
> other than our own. That would get rid of practically all malware- and
> adware-related crashes, but also of all "avtivirus" tools tinkering with
> our actions and a lot of add-ons, possibly/probably also of plugins (but
> we could still allow NPAPI loading binaries).
If most of them are malware related, then there are probably not much we
can do to avoid them. But maybe if we know that a particular crash is
related to malware we could tell the user?
> I don't think that would be feasible, but it would reduce the crashes
> Jesper seems to be worried about, and also most other startup crashes
> (that "query" for fast-repeated crashes favors startup crashes being the
> vast majority).
So maybe my query is not that good an approximation of what I was trying
to measure. I did not specifically intend to favor startup crashes.
Except maybe, if they happen on every startup.
Jesper Kristensen
> You can't run SQL queries directly on database, and you probably will
> just have some exhaustive queries time out on the crash-stats web
> interface, but you can do some interesting analysis of crashes using the
> crash summary text files that get generated every day.
Very interesting, I didn't know about that. Thank you.
> here is the top crash list, and crash counts, for signatures on firefox
> 5 where crashes have a time since last crash less than 60 seconds.
I think I was thinking about something longer, like 5 days. I will try
to experiment if I get time to do it.
-
Jesper Kristensen
Chris Hofmann
yeah, just grab files from multiple days to do this. I suspect you
might see small variations over time, but the crashes will be largely
the same. here is the list for july 1-6 with associated bug numbers for
the signatures.
$ awk -F\t '$6 < 60 && $8 ~ /5.0/ {print $1,$15}' 2011070* | sort | uniq
-c | sort -nr | head -20
3254 send 467167,593842,614966
2978 no sig 413534,512730
2062 RtlpWorkerCallout 599354
992 RtlpTpWorkCallback 647366
962 BaseThreadStart 524944
866 arena_dalloc_small | arena_dalloc | free | CloseDir 606666
660 vksaver.dll@0x3d66 614966
627 XPCWrappedNative::GetNewOrUsed(XPCCallContext&, xpcObjectHelper&,
XPCWrappedNativeScope*, XPCNativeInterface*, int, XPCWrappedNative**) 603075
613 js::mjit::EnterMethodJIT(JSContext*, JSStackFrame*, void*,
js::Value*) 595351,604371
525 js_XDRScript(JSXDRState*, JSScript**) 648022
449 _PR_MD_SEND 467167,489533
379 vksaver3.dll@0x2e55 614966
335 __RtlUserThreadStart 663466
333 nsTArray<ObserverRef,
nsTArrayDefaultAllocator>::AppendElements<ObserverRef>(ObserverRef
const*, unsigned int) |
nsObserverList::FillObserverArray(nsCOMArray<nsIObserver>&) 658780
324 PR_Write 666637
322 BaseThreadInitThunk 601587
319 WSARecv
312 @0x1a2710 665067
310 js::Interpret(JSContext*, JSStackFrame*, unsigned int,
JSInterpMode) 606960,637267
297 connect 538767
Robert Kaiser
> If most of them are malware related, then there are probably not much we
> can do to avoid them. But maybe if we know that a particular crash is
> related to malware we could tell the user?
Yes, I think we should work on that, and I actually have a few ideas on
that. I'll make sure we'll investigate necessities, possibilities and
options for that in the next months, but I currently have some
higher-priority items on my plate.
> So maybe my query is not that good an approximation of what I was trying
> to measure. I did not specifically intend to favor startup crashes.
> Except maybe, if they happen on every startup.
The nature of startup crashes is that they usually happen on every
startup, and that's why you're favoring them in that stat. I think we
need to get some measure in so we are quite likely to actually start
successfully after a few startup crashes. IMHO, that could be done by
starting in safe mode (potentially even with loading of any third-party
libraries disabled, if possible) when we detect a number of startup
crashes (ones with <60s run time) in a row. IIRC, there's a bug filed on
that.
Alexander Limi
> The nature of startup crashes is that they usually happen on every startup,
> and that's why you're favoring them in that stat. I think we need to get
> some measure in so we are quite likely to actually start successfully after
> a few startup crashes. IMHO, that could be done by starting in safe mode
> (potentially even with loading of any third-party libraries disabled, if
> possible) when we detect a number of startup crashes (ones with <60s run
> time) in a row. IIRC, there's a bug filed on that.
Underway in:
https://wiki.mozilla.org/Support/Firefox_Features/Clean_up_user_profile
--
Alexander Limi · Firefox UX Team · @limi <http://twitter.com/limi> ·
limi.net
Robert Kaiser
> On Fri, Jul 8, 2011 at 6:10 AM, Robert Kaiser<ka...@kairo.at> wrote:
>
>> The nature of startup crashes is that they usually happen on every startup,
>> and that's why you're favoring them in that stat. I think we need to get
>> some measure in so we are quite likely to actually start successfully after
>> a few startup crashes. IMHO, that could be done by starting in safe mode
>> (potentially even with loading of any third-party libraries disabled, if
>> possible) when we detect a number of startup crashes (ones with<60s run
>> time) in a row. IIRC, there's a bug filed on that.
>
>
> Underway in:
> https://wiki.mozilla.org/Support/Firefox_Features/Clean_up_user_profile
Nice! And for the question in 5. this is "new work" as well.