Crash in [@ nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) ]

RESOLVED WORKSFORME

Status

()

Core
Networking: HTTP
--
critical
RESOLVED WORKSFORME
8 years ago
7 years ago

People

(Reporter: Scoobidiver (away), Unassigned)

Tracking

({crash})

Trunk
x86
Windows 7
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 beta5+)

Details

(Whiteboard: [likely caused by IDM 7.*], crash signature)

(Reporter)

Description

8 years ago
Build : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100828
Firefox/4.0b5pre

This is a new crash signature which has been introduced by this build and it is
still the #2 crasher for this build.

http://crash-stats.mozilla.com/report/index/e049bf4b-8a8c-400c-9fe1-ef1012100828
Signature	nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*)
UUID	e049bf4b-8a8c-400c-9fe1-ef1012100828
Time 	2010-08-28 06:19:38.771868
Uptime	1202
Last Crash	1207 seconds (20.1 minutes) before submission
Install Age	1343 seconds (22.4 minutes) since version was first installed.
Product	Firefox
Version	4.0b5pre
Build ID	20100828040640
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 26 stepping 4
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x429c0000

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 		@0x429c0000 	
1 	xul.dll 	nsObserverService::NotifyObservers 	xpcom/ds/nsObserverService.cpp:182
2 	xul.dll 	nsHttpHandler::NotifyObservers 	netwerk/protocol/http/nsHttpHandler.cpp:550
3 	xul.dll 	nsHttpHandler::OnModifyRequest 	netwerk/protocol/http/nsHttpHandler.h:190
4 	xul.dll 	nsHttpChannel::AsyncOpen 	netwerk/protocol/http/nsHttpChannel.cpp:3567
5 	xul.dll 	nsScriptLoader::StartLoad 	content/base/src/nsScriptLoader.cpp:327
6 	xul.dll 	nsScriptLoader::ProcessScriptElement 	
7 	xul.dll 	nsScriptElement::MaybeProcessScript 	content/base/src/nsScriptElement.cpp:197
8 	xul.dll 	nsHTMLScriptElement::MaybeProcessScript 	content/html/content/src/nsHTMLScriptElement.cpp:551
9 	xul.dll 	nsHTMLScriptElement::BindToTree 	content/html/content/src/nsHTMLScriptElement.cpp:409
(Reporter)

Updated

8 years ago
blocking2.0: --- → ?
Keywords: crash
Do we have any idea of the regression range here?
Hrm.  Nothing obvious in there.... (e.g. no new HTTP observers I can see).

There _were_ various necko changes, though...  Could those be an issue?
Component: XPCOM → Networking: HTTP
QA Contact: xpcom → networking.http

Comment 4

8 years ago
Does this correlate against any extensions? I'm kinda betting a scriptable HTTP observer is involved, based on bug 591880. I wonder if we the observer service has a latent bug, or if the xpconnect implementation of weak references is broken.
blocking2.0: ? → final+

Comment 5

8 years ago
beta5, based on the topcrasheriness.
blocking2.0: final+ → beta5+
The vast majority of the most recent crashes (I looked at 26) have this add-on:
 	mozilla_cc@internetdownloadmanager.com  	7.1.1
I've seen a few with version 7.1.2 as well.

There were two, however, that did not have this add-on (they had no add-ons in fact):
bp-ae192a8b-65a7-4663-874b-7e5bb2100828
bp-19f5bd7d-1d19-4871-8679-291b72100828

Comment 7

8 years ago
100% (72/72) vs.  20% (794/3882) mozilla_cc@internetdownloadmanager.com (IDM CC, https://addons.mozilla.org/addon/6973)

If I'm reading that right, that's the extension common to 72 of the crashes, out of 272. Does the 72 figure mean that 272-72 of the crashes had no addons installed?
Didn't we blocklist IDM with bug 580393?
I should note that the web interface didn't always identify IDM as itself, even though the emid was right.

Updated

8 years ago
Depends on: 592125
Whiteboard: [likely caused by IDM 7.*]

Comment 10

8 years ago
there is a lower volume crash with these signatures that have been around for
awhile.  The data shows a few users hitting that still.  

count signature release build (from crash data on aug 25,26,27)

   1 @0x0 | nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.0 2008051206
   2 @0x0 | nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.6.8 20100722155716
   2 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.1b3 20090304233338
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.1b3 20090305152042
   2 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.6.3 20100401080539
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.6.8 20100722150226
  12 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 3.6.8 20100722155716



Then the  big ramp on 4.0b5pre builds happens after 20100828040640


count signature release build (from crash data on aug 28)

   4 @0x0 | nsObserverService::NotifyObservers(nsISupports*, char const*,
unsigned short const*) 4.0b5pre 20100828040640
   4 PL_DHashTableOperate | nsObserverService::NotifyObservers(nsISupports*,
char const*, unsigned short const*) 4.0b5pre 20100828040640
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned
short const*) 3.5.11 20100701023340
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned
short const*) 3.5.5 20091102152451
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned
short const*) 3.6.6 20100625231939
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned
short const*) 3.6.8 20100722155716
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned
short const*) 4.0b4 20100818132640
 107 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned
short const*) 4.0b5pre 20100828040640


count signature release build (from crash data on aug 29)

   1 @0x0 | nsObserverService::NotifyObservers(nsISupports*, char const*,
unsigned short const*) 3.6.8 20100722155716
   6 @0x0 | nsObserverService::NotifyObservers(nsISupports*, char const*,
unsigned short const*) 4.0b5pre 20100828040640
   3 PL_DHashTableOperate | nsObserverService::NotifyObservers(nsISupports*,
char const*, unsigned short const*) 4.0b5pre 20100828040640
   1 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned
short const*) 3.1b3 20090304233338
   4 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned
short const*) 3.6.8 20100722155716
  89 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned
short const*) 4.0b5pre 20100828040640

Comment 11

8 years ago
Seeing zero crashes here for the 20100831 nightly. The first crash reported on the 20100830 nightly has a 'Date' of 20100830 at around 6am. Assuming timezone is MVT, and that (if it's time-of-submit and not time-crashdata-was-processed-and-posted-on-crashstats) 6 hours is enough time to see it appear on crash-stats, then this is fixed.

Comment 12

8 years ago
Let's call it and reopen if necessary.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

7 years ago
Crash Signature: [@ nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) ]
You need to log in before you can comment on or make changes to this bug.