Last Comment Bug 503946 - Crashes on startup [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ]
: Crashes on startup [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject...
Status: RESOLVED DUPLICATE of bug 542203
[crashkill][crashkill-thirdparty][cra...
: crash
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: 1.9.1 Branch
: x86 Windows XP
: -- critical (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 542421 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-13 13:55 PDT by Matthew Middleton (:zzxc)
Modified: 2011-06-13 10:01 PDT (History)
17 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments

Description Matthew Middleton (:zzxc) 2009-07-13 13:55:45 PDT
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.
Comment 1 timeless 2009-07-13 17:45:29 PDT
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
Comment 2 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2009-07-14 02:20:04 PDT
What is "Live Chat"? Some addon?
Comment 3 Matthew Middleton (:zzxc) 2009-07-14 05:13:35 PDT
Live chat is part of support.mozilla.com, https://wiki.mozilla.org/Support/Live_Chat
Comment 4 Matthew Middleton (:zzxc) 2009-07-14 06:14:51 PDT
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 .
Comment 5 Mike Beltzner [:beltzner, not reading bugmail] 2009-07-21 20:47:14 PDT
This seems like INVALID, but we'll leave it open for dupe finding.
Comment 6 Tanner Filip [:tanner] 2009-09-11 18:27:02 PDT
I just saw this crash while helping a user. A clean install solved it, as zzxc said, in Comment 0
Comment 7 Jesse Ruderman on Windows 2009-10-23 15:35:39 PDT
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.

*** This bug has been marked as a duplicate of bug 519357 ***
Comment 8 chris hofmann 2010-01-26 07:07:52 PST
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?
Comment 9 chris hofmann 2010-01-26 07:24:01 PST
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
Comment 10 chris hofmann 2010-01-26 07:27:18 PST
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
Comment 11 chris hofmann 2010-01-26 07:36:50 PST
> 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.
Comment 12 John J. Barton 2010-01-26 07:54:48 PST
The information in comment 1 shows a crash 10 minutes after startup.
Comment 13 chris hofmann 2010-01-26 08:26:32 PST
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
Comment 14 chris hofmann 2010-01-26 08:41:24 PST
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.
Comment 15 chris hofmann 2010-01-26 18:10:48 PST
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
Comment 16 chris hofmann 2010-01-26 18:21:27 PST
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**) ]
Comment 17 Dave Garrett 2010-01-26 20:33:46 PST
*** Bug 542421 has been marked as a duplicate of this bug. ***
Comment 18 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2010-01-27 00:23:20 PST
Do we know what changed in yslow to trigger this?
Comment 19 chris hofmann 2010-01-27 11:41:30 PST
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
Comment 20 chris hofmann 2010-01-27 11:49:55 PST
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.
Comment 21 Marcia Knous [:marcia - use ni] 2010-01-27 15:59:09 PST
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.
Comment 22 Henrik Skupin (:whimboo) 2010-01-30 16:21:37 PST
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.

*** This bug has been marked as a duplicate of bug 542203 ***

Note You need to log in before you can comment on or make changes to this bug.