Closed Bug 503946 Opened 15 years ago Closed 14 years ago

Crashes on startup [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ]

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Version:
1.9.1 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 542203
Tracking Flags:
Tracking Status
blocking1.9.1 --- -

People

(Reporter: zzxc, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [crashkill][crashkill-thirdparty][crashkill-outreach][explosive])

Crash Data

There have been several reports of bp-4df83fb0-dc17-49ea-9b6c-601372090706 in Live Chat, all with crashes on startup.  In both cases that were confirmed solved, a clean installation (installing Firefox again into an empty folder) fixed the crash.  This is currently the #55 topcrash for Firefox 3.5.
Signature	nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
UUID	4df83fb0-dc17-49ea-9b6c-601372090706
Time 	2009-07-06 11:17:53.231845
Uptime	177
Last Crash	566 seconds before submission
Product	Firefox
Version	3.5
Build ID	20090624025744
Branch	1.9.1
OS	Windows NT
OS Version	6.0.6001 Service Pack 1
CPU	x86
CPU Info	AuthenticAMD family 16 model 2 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x3c85
User Comments	
Processor Notes 	
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsXHREventTarget::GetParentObject 	content/base/src/nsXMLHttpRequest.h:217
1 	xul.dll 	nsEventTargetSH::PreCreate 	dom/src/base/nsDOMClassInfo.cpp:7423
2 	xul.dll 	XPCWrappedNative::GetNewOrUsed 	js/src/xpconnect/src/xpcwrappednative.cpp:416
3 	xul.dll 	XPCConvert::NativeInterface2JSObject 	js/src/xpconnect/src/xpcconvert.cpp:1146
4 	xul.dll 	nsXPConnect::WrapNativeToJSVal 	js/src/xpconnect/src/nsXPConnect.cpp:1260
5 	1273446.dll 	1273446.dll@0x11b79a
What is "Live Chat"? Some addon?
Live chat is part of support.mozilla.com, https://wiki.mozilla.org/Support/Live_Chat
This crash seems to be caused by a bad XPCOM component in the 'components' folder.  All of the crash reports with this signature show a module with a reported version of "3.0.0.0" and with a random number as the filename.  The modules listings on crash-stats contain lines such as:

1288990.dll  	3.0.0.0  	FF6C60C0FDF24F8FB258C9A357F2E0B01  	FirefoxExt30.pdb

A user who had reported this crash on support.mozilla.com sent me a copy of the entire install folder, which contained this component.  An anti-virus analysis of the file is at http://www.virustotal.com/analisis/af4d1cfe5d2c77f15ca32ba1c9ccacc8d41a64db3229b516a8cda316b7f74ef7-1247519639 .
blocking1.9.1: --- → ?
status1.9.1: --- → wanted
This seems like INVALID, but we'll leave it open for dupe finding.
blocking1.9.1: ? → -
status1.9.1: wanted → ?
I just saw this crash while helping a user. A clean install solved it, as zzxc said, in Comment 0
Firefox 3.6 will no longer load random components from its components/ folder (see bug 519357).

Given the random filenames, this sounds like malware, so it's likely that future versions of the malware will hook into Firefox using another mechanism.  But they probably won't crash Firefox in the same way.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
opening back up to catch possible dupes to the y!slow release.

many people reporting problems on update to yslow to v 2.0.5

merely typing on the google search tool in the top right crashes firefox. this happend right after i updated yslow to v 2.0.5

top of the stack looks the same as above.

http://crash-stats.mozilla.com/report/index/8f784fd9-fb53-4d76-a86c-f2fcc2100125

Frame  	Module  	Signature [Expand]  	Source
0 	xul.dll 	nsXHREventTarget::GetParentObject 	content/base/src/nsXMLHttpRequest.h:217
1 	xul.dll 	nsEventTargetSH::PreCreate 	dom/src/base/nsDOMClassInfo.cpp:7421
2 	xul.dll 	XPCWrappedNative::GetNewOrUsed 	js/src/xpconnect/src/xpcwrappednative.cpp:416
3 	xul.dll 	XPCConvert::NativeInterface2JSObject 	js/src/xpconnect/src/xpcconvert.cpp:1146
4 	xul.dll 	XPCConvert::NativeData2JS 	js/src/xpconnect/src/xpcconvert.cpp:472
5 	xul.dll 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:2543
6 	xul.dll 	XPC_WN_GetterSetter 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1622
7 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1386
8 	js3250.dll 	js_InternalInvoke 	js/src/jsinterp.cpp:1447
9 	js3250.dll 	js_GetPropertyHelper 	js/src/jsobj.cpp:4333
10 	js3250.dll 	js_Interpret 	js/src/jsinterp.cpp:4451
11 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1394
12 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1697
13 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:569
14 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
15 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
16 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
17 	xul.dll 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:2456

currently ramped to #16 top crash in 3.6

http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=nsXHREventTarget%3A%3AGetParentObject%28nsIScriptGlobalObject**%29&version=Firefox%3A3.6

I wonder if there is a way to keep people from tripping on this?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
pretty big explosion of crashes on this yesterday

date sXHREventTarget::GetParentObjectcrashes
20100120-crashdata 230 sXHREventTarget::GetParentObject
20100121-crashdata 181 sXHREventTarget::GetParentObject
20100122-crashdata 146 sXHREventTarget::GetParentObject
20100123-crashdata 148 sXHREventTarget::GetParentObject
20100124-crashdata 145 sXHREventTarget::GetParentObject
20100125-crashdata 1950 sXHREventTarget::GetParentObject
checking --- 20100125-crashdata.csv sXHREventTarget::GetParentObject
release total-crashes
              sXHREventTarget::GetParentObject crashes
                         pct.
all     256970  1950    0.00758843
3.0.15  1620            0
3.0.16  1047            0
3.5.5   4599    24      0.00521853
3.5.6   3562    15      0.00421112
3.5.7   133251  668     0.0050131
3.6     59319   1211    0.020415
3.6b5   2598    1       0.000384911
3.6b4   1144            0
3.6b3   591             0
3.6b2   615             0
3.6b1   904     2       0.00221239
> currently ramped to #16 top crash in 3.6

actually now ranked #2 and #3 if you look at the 1 day or 3 day reports.
The information in comment 1 shows a crash 10 minutes after startup.
checking --- 20100125-crashdata.csv sXHREventTarget::GetParentObject
Correlation to startup
1950 total crashes for sXHREventTarget::GetParentObject on 20100125-crashdata.csv
1085 start up crashes inside 3 minutes
jorge has sandboxed yslow so additional users won't automatically update to v2.0.5 while a fix is being worked on in the addon.
Whiteboard: [crashkill][crashkill-thirdparty][crashkill-outreach][explosive]
all of the crashes for this signature are on windowa

 897 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 5.1.2600 Service Pack 3
 343 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 6.1.7600
 340 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 6.0.6002 Service Pack 2
 222 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 5.1.2600 Service Pack 2
  48 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 5.2.3790 Service Pack 2
  43 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 6.0.6001 Service Pack 1
  32 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 6.1.7100
  12 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 6.0.6000
   3 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 6.0.6002 Service Pack 2, v.113
   2 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 5.1.2600 Service Pack 3, v.5857
   2 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 5.1.2600 Service Pack 3, v.3311
   2 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 5.1.2600 Dodatek Service Pack 3
   1 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 6.1.7127
   1 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 5.1.2600 Service Pack 3, v.5755
   1 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 5.1.2600
   1 _purecall | nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) Windows NT 6.0.6002 Service Pack 2
ok, looking deeper the mac form of the crash seems to be showing up under a different signature  like the report

http://crash-stats.mozilla.com/report/index/fb40ca71-f850-4c2d-825b-b817a2100125

 [@ nsEventTargetSH::PreCreate(nsISupports*, JSContext*, JSObject*, JSObject**) ]
Do we know what changed in yslow to trigger this?
crashes continued to increase during the day (up to midnight pacific) yesterday, which is surprising.

20100124-crashdata 145 nsXHREventTarget::GetParentObject
20100125-crashdata 1950 nsXHREventTarget::GetParentObject
20100126-crashdata 11731 nsXHREventTarget::GetParentObject
dbaron checked some early data after 2.0.6 was released and couldn't find instances of 2.0.6 crashing.

marcia is going to check that again looking at more data since last night.
I reviewed a number of crash reports from today on Mac, and in all cases they were using Version 2.0.5 of yslow. Will continue monitoring the reports from the other platforms to confirm that only 2.0.5 is crashing.
It's the same bug as bug 542203. I will dupe this because bug 542203 already offers a bit more information and also a diff between version 2.0.5 and 2.0.6 of YSlow.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
status1.9.1: ? → ---
Resolution: --- → DUPLICATE
Crash Signature: [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ]
You need to log in before you can comment on or make changes to this bug.