twice as many "no signature" and other crashes in firefox 3.5.3 as 3.0.14

RESOLVED INCOMPLETE

Status

()

Firefox
General
RESOLVED INCOMPLETE
8 years ago
4 years ago

People

(Reporter: chris hofmann, Unassigned)

Tracking

3.5 Branch
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [notacrash])

(Reporter)

Description

8 years ago
looking at the incoming crashes each day I see stuff like below for 20090921

count  signature  version.

1719 \N 3.5.3
 737 \N 3.0.14

3.5.3 and 3.0.14 currently have close to the same number of users.

I think ted or lars once told me why "\N - no signature" might show up in the data but I forget what that reason was.  Can you refresh?  "No signature" might actually be the current top crash for 3,5,3

I guess this might actually be a breakpad, soccoro, core, or firefox bug, so we can move it once we figure out where it should go and where it might have the most impact in getting this crashes understood and fixed.
(Reporter)

Updated

8 years ago
Summary: twice as many "no signature" crashes 3.5.3 as 3.0.14 → twice as many "no signature" crashes in firefox 3.5.3 as 3.0.14
(Reporter)

Comment 1

8 years ago
there are actually several crashes that are double the rate or more in 3.5.x

1680 @0x0 3.5.3
684  @0x0 3.0.14  https://bugzilla.mozilla.org/buglist.cgi?bug_id=497251,512486,507775,504308,418941 -- several bugs that speculate about out of memory conditions.


1032 RtlpWaitForCriticalSection 3.5.3
718  RtlpWaitForCriticalSection 3.0.14  bug 511757 flash (out of memory?)

875 CFReadStreamGetStatus 3.5.3
366 CFReadStreamGetStatus 3.0.14   bug 498971 flash (out of memory?)

 816 nsStyleSet::FileRules(int (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*) 3.5.3  - bug 492675 MyWebSearch toolbar
 444 nsStyleSet::AddImportantRules(nsRuleNode*, nsRuleNode*) 3.0.14 -- bug 466024 ask toolbar or mywebsearch toolbar and  Bug 507457 ?  aol webmail
(Reporter)

Updated

8 years ago
Summary: twice as many "no signature" crashes in firefox 3.5.3 as 3.0.14 → twice as many "no signature" and other crashes in firefox 3.5.3 as 3.0.14
(Reporter)

Updated

8 years ago
Depends on: 511757, 498971, 507457, 492675
(Reporter)

Updated

8 years ago
Depends on: 497251, 512486, 507775, 504308, 418941
(Reporter)

Comment 2

8 years ago
The number of reports with "no signature" (aka ""), as opposed to the null signature ("\N")  is also dramatically higher in 3.5.3

count-on-20090921  signature  version

 425  "" 3.5.3
  84  "" 3.0.14
Aren't there just more overall reports?
(Reporter)

Comment 4

8 years ago
the key things to understand are:

1) there are about the same number of users
2) there are more total crash reports for 3.5.3 than 3.0.14
 about double...

http://people.mozilla.com/~chofmann/crash-data/user-crash-growth-rate-3014-353.png

3) there are more overall reports on 3.5.x than 3.0.x for some signatures

4) there are fewer overall reports on 3.5.x than 3.0.x for some signatures (e.g. we partically fixed a crashing problem) 

5) There are crashing signatures in 3.0.x that don't appear as crashes in 3.5.x (e.g. we totally fixed the crash bug, or the signature morfed to a new one.)

6) There are new crash signatures in 3.5.x that we haven't seen before. (new crash bugs.)

we have investigations underway in a lot of different bugs for items 4,5, and 6.

This bug is about looking at item 3, and to try and understand why we see big increases in some of the top crash signatures in 3.5.x.  Somewhere, something, or somethings have gotten worse.

The fact that we also have twice as many total number of signatures in 3.5.x as 3.0.x when we have the same number of users also needs investigation.

awk -F\t  '{print $1,$8}'  20090921* | sort | uniq -c |  grep 3.0.14 | wc
   11633   

awk -F\t  '{print $1,$8}'  20090921* | sort | uniq -c |  grep 3.5.3 | wc
   19167 

Maybe that is a different bug.  Maybe there is some connection.

One theory might be that the later versions of firefox, flash, or other wide spread plugin is using more memory, we are running out of memory, and tickling existing low memory crash bugs in a more serious way in 3.5.x.  This kind of theory might also mean we generate more a random and broader number stack signatures.
No longer depends on: 507775
No longer depends on: 504308
(Reporter)

Updated

8 years ago
Blocks: 524507
I have no idea what the expected outcome of this bug is supposed to be.
(Reporter)

Comment 6

8 years ago
(In reply to comment #5)
> I have no idea what the expected outcome of this bug is supposed to be.

stuff like bug https://bugzilla.mozilla.org/show_bug.cgi?id=528798

and more, like on steroids, man.

Comment 7

4 years ago
time to close?
Flags: needinfo?(chofmann)
Whiteboard: [notacrash]
(Reporter)

Comment 8

4 years ago
sí, unless kairo or someone else tracks this now and finds it useful.  version to version tracking of signatures is probably a lot easier now than what it was when this bug was filed.  if its not then a new bug to provide that reporting might be worthwhile.
Flags: needinfo?(chofmann)

Comment 9

4 years ago
We don't have "no signature" any more, and we actually even managed to significantly reduce the "empty" signature that replaced it by reserving memory for OOM cases. We are tracking OOM and other issues intensely in other bugs now so this one isn't needed any more.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.