542203 - Crash in [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] using Google search & "escaping" search entry [triggered by Firebug and YSlow] also mac and linux [@nsEventTargetSH::PreCreate(nsISupports*, JSContext*, JSObject*, JSObject**) ]

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect)

Description

[Frank Zimmer]

Typing some letters into the search box, adopting them by "backspace" or whatever
and then pressing the escaepe button on the keyboard will FF crash.
Using Google as search engine.
I will try also some other ones right now after submitting this case

Reproducible always !

Several automatic crash reports are sent out.

Comment 1

[Frank Zimmer]

See crahsreports :

bp-3b33e9e9-90f2-402b-81df-d0bcc2100126	1/26/2010	2:14 PM
bp-df8e30c2-a1ca-4d72-a640-265532100126	1/26/2010	2:13 PM
bp-8c573b0b-7bf0-4a72-8c2d-84cac2100126	1/26/2010	2:12 PM
bp-9017420f-40ee-47e5-9ade-760162100126	1/26/2010	2:05 PM
bp-e3cf12b3-e921-405e-a666-377852100126	1/26/2010	1:59 PM
bp-258a416a-5299-4731-a372-244642100126	1/26/2010	1:58 PM
bp-7e6f8c5e-d4e8-4a1f-aaa2-d4fc42100126	1/26/2010	1:58 PM
bp-65169ee5-4765-470f-a45b-9c2552100126	1/26/2010	1:58 PM
bp-3bfd5835-977d-4744-afb5-95b732100126	1/26/2010	1:57 PM

Comment 3

[Tobias (:Tobbi) Markus]

I think this is better to be dupped to #519357. 

Frank: What DLL files do you have in the components subfolder of the Firefox installation folder?

Comment 4

[(not currently active) Ted Mielczarek]

His reports are with Firefox 3.6, which contains the changes from bug 519357, which means that if he's still experiencing this crash, then it can't be fixed by that bug.

Comment 5

[Frank Zimmer]

Hi
under the same crashreport ID's i found a comment which has the YSlow extension in mind. I did disable Firebug and Yslow and now the problem is away.
But i am quite sure that with the 3.6Pre versions this wasn't the case.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I do not believe that Firebug installs anything into the components folder of Firefox! It's a regular add-on and can not do such a quirks. That's why I agree with Ted. Lets reopen and CC some guys from Firebug.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Frank, what happens when you have enabled Firebug but not YSlow? Does it also prevent the crash?

Comment 8

[Frank Zimmer]

Enabling Firebug with different modules activated does not lead to the crash !
Enabling YSlow -> crash.

But when i remember right this was not the case with FF 3.6preXXX

Frank

Comment 9

[Tobias (:Tobbi) Markus]

Now that chofmann reopened the other bug, should we dupe against this one, once more?

Comment 10

[John J. Barton]

(In reply to comment #6)
> I do not believe that Firebug installs anything into the components folder of
> Firefox! 

This is correct, Firebug does not modify firefox/components

The crash reports in comment #1 have multiple different paths to the same function. It's likely then that data structure damage was done before we get to the stack traces shown there. I don't know about YSlow.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

John, you can find it here: https://addons.mozilla.org/de/firefox/addon/5369. It simply does some measurements for web page loading.

Comment 13

[John J. Barton]

This crash is not caused by Firebug.

YSlow devs report they have posted a new version on AMO to solve a problem of YSlow in Firefox resulting in a crash.

http://tech.groups.yahoo.com/group/exceptional-performance/message/1416

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Frank does it work for you with version 2.0.6 now? It's already available (https://addons.mozilla.org/de/firefox/addon/5369)

Comment 15

[Frank Zimmer]

Hi,

i have recently updated YSlow to 2.0.6 and until now no crash is happening again.
Seems stable now.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Good to hear that. Looks like it has been fixed on their end. Let's resolve this bug.

Comment 17

[(not currently active) Ted Mielczarek]

Was YSlow using any binary components? If not, we should find the underlying cause here. Pure JS extensions should not be able to crash the browser.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Good call, Ted. No, YSlow doesn't use any binary components. So I suspect it might be a side-effect with the integration in Firebug. Lets reopen for more investigation.

Frank, do you have the version 2.0.5 of YSlow still available? It has been removed from AMO. Btw. do you also get the crash with only YSlow enabled but Firebug disabled?

Comment 19

[John J. Barton]

(In reply to comment #18)
> Good call, Ted. No, YSlow doesn't use any binary components. So I suspect it
> might be a side-effect with the integration in Firebug. Lets reopen for more
> investigation.

The problem here is likely to be a bug in Firefox exposed by YSlow code.

You should contact YSlow developers and ask them what they did to fix 2.0.6. That would rapidly pin point the problem.

> 
> Frank, do you have the version 2.0.5 of YSlow still available? It has been
> removed from AMO. Btw. do you also get the crash with only YSlow enabled but
> Firebug disabled?

YSlow is a Firebug extension, it cannot run without Firebug enabled.

Comment 20

[Damon Sicore (:damons)]

We are in process of blocking YSlow 2.0.5.  It's causing at least two other top crashes as well:

http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=XPCWrappedNative%3A%3AGetNewOrUsed%28XPCCallContext%26%2C%20nsISupports%2A%2C%20XPCWrappedNativeScope%2A%2C%20XPCNativeInterface%2A%2C%20nsWrapperCache%2A%2C%20int%2C%20XPCWrappedNative%2A%2A%29&version=Firefox%3A3.6

And:

http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=nsEventTargetSH%3A%3APreCreate%28nsISupports%2A%2C%20JSContext%2A%2C%20JSObject%2A%2C%20JSObject%2A%2A%29&version=Firefox%3A3.6

Comment 21

[John J. Barton]

Did anyone reach out to YSlow?  They already updated the extension so what's to block?

Comment 22

[Johnny Stenback (:jst)]

(In reply to comment #19)
> (In reply to comment #18)
> > Frank, do you have the version 2.0.5 of YSlow still available? It has been
> > removed from AMO. Btw. do you also get the crash with only YSlow enabled but
> > Firebug disabled?
> 
> YSlow is a Firebug extension, it cannot run without Firebug enabled.

Really? I just installed only YSlow (2.0.5), seems to "work". Not sure if it works as expected, but it gives me page load numbers etc.

And in case there's any confusion about the cause of this, http://people.mozilla.com/crash_analysis/20100127/20100127_Firefox_3.6-interesting-addons.txt.gz points directly at yslow as the cause of this, and in that data you can also see that not all yslow users/installations have Firebug as well.

Comment 23

[John J. Barton]

http://developer.yahoo.com/yslow/help/
under Installing YSlow says
YSlow needs Firebug to run.

Comment 24

[Johnny Stenback (:jst)]

Hmm, too bad they don't seem to enforce that...

And yes, the YSlow team knows about this and know that we're blocking 2.0.5.

Comment 25

[Johnny Stenback (:jst)]

Attachment: yslow-2.0.5.xpi

I got this from the YSlow developers.

Comment 26

[John J. Barton]

All JS, no components

Comment 27

[John J. Barton]

At the bottom of their overlay, browser.xul it has:
   firefox standalone version yslow panel
So it looks like they have a non-firebug mode.

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I can reproduce the crash now and it really only happens with Firebug enabled. Adding back Firebug to the summary which has been removed before. I will attach a windbg stack in a short moment.

Comment 29

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: WinDBG stack

To reproduce this crash simply do the following steps:

1. Install Firebug 1.5 and YSlow 2.0.5
2. Select Auto-run from inside the context menu of the YSlow button in the status bar
3. Enter some characters into the search bar

Stack info:

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_xul.dll!nsXHREventTarget::GetParentObject

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_NULL_CLASS_PTR_DEREFERENCE_xul!nsXHREventTarget::GetParentObject+7


As it looks like the following call returns a null pointer:

target->GetParentObject(getter_AddRefs(native_parent));

http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMClassInfo.cpp#7491

Comment 30

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This is the topcrasher #2 for Firefox 3.6 at the moment:

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

All those reports clearly state that users have Firebug and YSlow installed.

Comment 31

[Frank Zimmer]

As already mentioned fro my side this is not longer occurring with YSlow 2.0.6
(at least a small workaround for the Enduser ;-)
I agree not for developpers

Comment 32

[John J. Barton]

(In reply to comment #28)
> I can reproduce the crash now and it really only happens with Firebug enabled.
> Adding back Firebug to the summary which has been removed before. I will attach
> a windbg stack in a short moment.

Henry perhaps we have a different meaning for "caused by". Neither Firebug nor YSlow can crash Firefox on purpose: we cannot cause it to exit through any action or neglect. That is built in to the wonderful design of the JS system.

Insisting on "caused by Firebug" may lead some to think that this bug can be "fixed by Firebug". That is not true. We will not be working on this bug. We cannot fix it, because we did not "cause" it.

Comment 33

[chris hofmann]

I looked at at a sample of about 100 reports from yesterday.

a small number have neither yslow or firebug installed
http://crash-stats.mozilla.com/report/index/ffbe0291-1965-4109-a443-be9462100127
http://crash-stats.mozilla.com/report/index/ff85ad3d-4a5f-4343-ae7d-e3a542100127
http://crash-stats.mozilla.com/report/index/ff6c617d-96bc-4923-b234-23ec42100127
http://crash-stats.mozilla.com/report/index/ff522c9b-cb7b-492b-988f-e3e652100127
http://crash-stats.mozilla.com/report/index/feca7692-a107-4439-8cec-b52a92100127
http://crash-stats.mozilla.com/report/index/fe7f71f5-6143-4936-bd06-a85f32100127
http://crash-stats.mozilla.com/report/index/fe635fa4-3425-4618-bbb1-dfbb42100127
http://crash-stats.mozilla.com/report/index/fdf7c949-1e4a-4619-9f6f-c3e952100127

some reports have only yslow 2.0.5 installed

http://crash-stats.mozilla.com/report/index/ffc59f69-0df2-4011-8762-2d1b32100127
	                    <td>[e-mail]</td>
	                    <td>2.0.5</td>

http://crash-stats.mozilla.com/report/index/ff11b938-6a41-4402-a642-056ab2100127
	                    <td>[e-mail]</td>
	                    <td>2.0.5</td>

http://crash-stats.mozilla.com/report/index/fecc414e-ad48-4e83-84d4-af0062100127
	                    <td>[e-mail]</td>
	                    <td>2.0.5</td>

http://crash-stats.mozilla.com/report/index/fe9ad522-ccc5-41ad-8515-369042100127
	                    <td>[e-mail]</td>
	                    <td>2.0.5</td>

http://crash-stats.mozilla.com/report/index/fdeb143a-c1be-4ecd-bedd-5fd652100127
	                    <td>[e-mail]</td>
	                    <td>2.0.5</td>
a few reports have

http://crash-stats.mozilla.com/report/index/ff38bb11-b2da-4aec-ba9f-f4a262100127
	                    <td>[e-mail]</td>
	                    <td>2.0.5</td>
	                    <td>[e-mail]</td>
	                    <td>1.4.5</td>

the vast majority of reports have the combination of

http://crash-stats.mozilla.com/report/index/ff42b8be-9ff0-4057-b2ab-3aca92100127
	                    <td>[e-mail]</td>
	                    <td>2.0.5</td>
	                    <td>[e-mail]</td>
	                    <td>1.5.0</td>

This would suggest that some combination of yslow 2.0.5 and firebug 1.5.0 makes the bug worse, but is not the entire problem.

what is confusing to me is why the update of users to yslow 2.0.5 caused the fast increased in crashes, but now the update of 2.0.6 seems to be happending so much slower?  10,300 reports submitted yesterday, while 2.0.6 was in the update channel.

20100125-crashdata 1950 nsXHREventTarget::GetParent
20100126-crashdata 11731 nsXHREventTarget::GetParent
20100127-crashdata 10300 nsXHREventTarget::GetParent


I guess that an infinite loop of crash on start up for some users once the once the problem was introducted might be getting in the way of completing the update.

I didn't find any yslow 2.0.6 crashes in my sample so we definitely need to move forward with trying to get users that update.  I also didn't find any instances where firebug was installed without yslow being there so I think we can assume firebug on its own is not the source of this crash.

Comment 34

[John J. Barton]

(In reply to comment #33)...
> what is confusing to me is why the update of users to yslow 2.0.5 caused the
> fast increased in crashes, but now the update of 2.0.6 seems to be happending
> so much slower?  10,300 reports submitted yesterday, while 2.0.6 was in the
> update channel.

Because users who have YSlow 2.0.5 are upgrading to FF 3.6 is my guess.

Comment 35

[chris hofmann]

I looked at another sample of 100 reports from late yesterday.

82% have yslow 2.0.5 with firebug 1.5.0 tagging along (1 report of firebug 1.4.5)
 8% have only yslow 2.0.5
10% don't have yslow or firebug

I also checked a sample from late on 2010 01 25 when the bug first got introduced.  The ratios look about the same, so it doesn't appear that only users with the yslow/firebug are left without getting speedier updates of yslow 2.0.6 to fix the crash.

Comment 36

[timeless]

Signature	nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
UUID	3b33e9e9-90f2-402b-81df-d0bcc2100126
Time 	2010-01-26 05:14:01.396459
Uptime	42
CPU Info	GenuineIntel family 6 model 15 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x6d756874

Crashing Thread
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsXHREventTarget::GetParentObject 	content/base/src/nsXMLHttpRequest.h:165
1 	xul.dll 	nsEventTargetSH::PreCreate 	dom/base/nsDOMClassInfo.cpp:7624
2 	xul.dll 	XPCWrappedNative::GetNewOrUsed 	js/src/xpconnect/src/xpcwrappednative.cpp:438
3 	xul.dll 	XPCConvert::NativeInterface2JSObject 	js/src/xpconnect/src/xpcconvert.cpp:1199
4 	xul.dll 	XPCConvert::NativeData2JS 	js/src/xpconnect/src/xpcconvert.cpp:471
5 	xul.dll 	XPCConvert::NativeData2JS 	js/src/xpconnect/src/xpcprivate.h:2974
6 	xul.dll 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:2809
7 	xul.dll 	XPC_WN_GetterSetter 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1784
8 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1360
9 	js3250.dll 	js_InternalInvoke 	js/src/jsinterp.cpp:1423
10 	js3250.dll 	js_GetPropertyHelper 	js/src/jsobj.cpp:4277
11 	js3250.dll 	js_Interpret 	js/src/jsops.cpp:1520
12 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1368
13 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1696
14 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:570
15 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
16 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
17 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102

for this crash, the pointer isn't anywhere near null.

Comment 37

[Zane U. Ji]

Attachment: JS Stack

Version of firefox is official 3.6. nsSearchSuggestions.js is also available at http://hg.mozilla.org/mozilla-central/annotate/5e174f186d31/toolkit/components/search/nsSearchSuggestions.js.

The parameter "nativeObj" passed to nsEventTargetSH::PreCreate points to a nsXPTCStubBase object rather than a nsXHREventTarget object, which is what nsEventTargetSH::PreCreate expects.

I also noticed that at line 659 in nsSearchSuggestions.js:
this._request.onreadystatechange = onReadyStateChange;
where the type of onreadystatechange is nsIDOMEventListener while onReadyStateChange is just a function. I am not sure if that is right.

Comment 38

[Olli Pettay [:smaug][[e-mail]]]

Zane, do you mean you can reproduce the crash somehow using nsSearchSuggestions.js? Or what? The JS stack seems to have lots of
Firebug code in it.

About onreadystatechange and functions; nsIDOMEventListener interface is
marked with [function] keyword, so any function can be used as a nsIDOMEventListener.

Comment 39

[John J. Barton]

The Firebug line numbers in the attachment are for the 'detrace' version of Firebug, so it's not so easy use them.

I think what Zane is trying to say is that the search suggestion code has an object which should be XHR but is not. When Firebug / YSlow run, then touch the XHR objects as part of the Net traffic analysis. That is what the call stack Zane attached shows. This touch causes a call that crashes because the object is not correctly an XHR.

Comment 40

[Zane U. Ji]

(In reply to comment #38)
> Zane, do you mean you can reproduce the crash somehow using
> nsSearchSuggestions.js? Or what? The JS stack seems to have lots of
> Firebug code in it.
> 
Yes. I can reproduce it by doing the steps listed in Comment 29.

> About onreadystatechange and functions; nsIDOMEventListener interface is
> marked with [function] keyword, so any function can be used as a
> nsIDOMEventListener.

OK.

Comment 41

[Zane U. Ji]

Attachment: Difference between yslow 2.0.5 and 2.0.6

Comment 43

[Zane U. Ji]

Attachment: Patch for yslow 2.0.5

After I applied the patch, firefox doesn't crash any more.

yslow implements its own http channel progress listener, which is fine. The problem is that the listener wraps another listener and forwards QueryInterface calls to the wrapped one. When we want the class information of yslow's listener at
http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/448d0d2d310c/js/src/xpconnect/src/xpcwrappednative.cpp#l399
and
http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/448d0d2d310c/js/src/xpconnect/src/xpcwrappednative.cpp#l423
the information of the wrapped one is returned. Firefox crashes when the wrong information is applied.

I don't know how to fix it and I won't have too much time in the next month. If anyone is interested, please take it over.

BTW: It seems that any JS object that forwards QueryInterface calls to another object should implement nsIClassInfo. Or firefox crashes when that object is accessed in JavaScript.

Comment 44

[Olli Pettay [:smaug][[e-mail]]]

peterv, any comments to comment 43?
You changed the code to require nsXHREventTarget.

Comment 45

[Zane U. Ji]

The class type shouldn't be hard coded. In yslow case, it is nsXPTCStubBase rather than nsXHREventTarget.

Comment 46

[Zane U. Ji]

Sorry if you're talking about nsXHREventTarget::GetParentObject.

Comment 47

[John J. Barton]

(In reply to comment #43)
...
> BTW: It seems that any JS object that forwards QueryInterface calls to another
> object should implement nsIClassInfo. Or firefox crashes when that object is
> accessed in JavaScript.

Zane, you wrote "BTW". Do you mean:
  1) Ultimately the root cause of this bug access to nsIClassInfo in cases where it is not set (one bug), or
  2) Another bug is here, access to nsIClassInfo crashes in cases where it is not set (2 bugs)?

JS code must not crash, no matter what it does or does not do.

Comment 48

[Zane U. Ji]

I found out the class information returned here 
info = do_QueryInterface(identity);
in XPCWrappedNative::GetNewOrUsed is incorrect.

The root cause is we don't verify it before using it.

Comment 50

[Peter Van der Beken [:peterv]]

Do you need to implement nsIClassInfo? I think just returning null should be enough.

Blindly forwarding QI is dangerous, handing out the classinfo from a different object is definitely not what you want to do.

Comment 51

[Zane U. Ji]

No. Null is acceptable. That yslow patch is just for demonstration.

Comment 53

[chris hofmann]

wonder if  Bug 544640 is also a dup/variant.  that signature is rising fast.

Comment 54

[chris hofmann]

Maybe this is just coincidence but it's a bit strange that such a high pct. of these crashes happen within a few seconds of 10 minutes after start up.

top times when the nsXHRE crashes happen around time shown in the second column
count time-since-start  sig
 270    600     nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
 252    601     nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  99    602     nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  53    603     nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  39    604     nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  19    605     nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  18    606     nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  13    5       nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  12    1       nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  11    6       nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  11    3       nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  10    607     nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  10    301     nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  10    2       nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  10    10      nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
out of 1143 total crashes on 20100129

is there any timed activity that kicks off around that time that might cause a conflict?

Comment 55

[chris hofmann]

re: comment 53 and 54

there does seem to be some interesting collection of crashes that start popping up around 10 minutes after startup.

this one starts up in high volume, but also XPCWrappedNative::GetNewOrUsed which is bug 544640

#crash
     seconds since startup
         signature

   1 599 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
   1 599 nsWindow::GetParentWindow(int)
   1 599 nsPseudoClassList::~nsPseudoClassList()
   1 599 nsCOMPtr<nsIDragSession>::~nsCOMPtr<nsIDragSession>() | nsStyleList::Destroy(nsPresContext*)
   1 599 msvcr80.dll@0xf880
   1 599 libflashplayer.so@0x24b311
   1 599 TextXtra.x32@0x232bb
   1 599 StrChrIA
   1 599 QuickTime.qts@0x17c2e8
   1 599 PlaceholderTxn::QueryInterface(nsID const&, void**)

 178 600 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  23 600 XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, nsWrapperCache*, int, XPCWrappedNative**)
  11 600 js3250.dll@0xef870
   3 600 @0x0 | XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, nsWrapperCache*, int, XPCWrappedNative**)
   2 600 xul.dll@0xa4fa20
   1 600 xul.dll@0x999570
   1 600 ssl_SetupIOMethods
   1 600 sqlite3WhereBegin
   1 600 radhslib.dll@0x3b6f
   1 600 nsHostResolver::Shutdown()

 183 601 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  28 601 XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, nsWrapperCache*, int, XPCWrappedNative**)
  13 601 js3250.dll@0xef870
  10 601 nsEventTargetSH::PreCreate(nsISupports*, JSContext*, JSObject*, JSObject**)
   6 601 @0x0 | XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, nsWrapperCache*, int, XPCWrappedNative**)
   3 601 dtoa
   2 601 xul.dll@0xa4fa20
   2 601 xul.dll@0xa4b24c
   2 601 js3250.dll@0xf14c0
   2 601 js3250.dll@0xef87b

  69 602 nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**)
  10 602 nsEventTargetSH::PreCreate(nsISupports*, JSContext*, JSObject*, JSObject**)
  10 602 XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, nsWrapperCache*, int, XPCWrappedNative**)
   2 602 @0x0 | XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, nsWrapperCache*, int, XPCWrappedNative**)
   1 602 xul.dll@0xa4fa20
   1 602 vlsp.dll@0x7a46
   1 602 nsNSSCertificate::destructorSafeDestroyNSSReference()
   1 602 js_SweepScopeProperties
   1 602 js_Interpret:912
   1 602 js_Interpret:904

Comment 56

[chris hofmann]

it looks like app.update.timer is set to 600000 miliseconds or 10 minutes as the default setting

Comment 57

[chris hofmann]

Attachment: graphical view showing when crashes happen after startup with the spike around the 10 minute mark

Comment 58

[John J. Barton]

The network layer monitoring available in the platform and used by Firebug (and YSlow) is global. It is triggered by the update network events.

Comment 59

[Peter Van der Beken [:peterv]]

I'm not sure why the 10 minutes is interesting, the updater uses XHR and we know that this crash is triggered the first time something uses an XHR.

Comment 60

[Zane U. Ji]

I tried to compare the nsISupport interfaces queried from the object and the class information. I thought I could ignore the class information (by setting it to nsnull) if those two are not equal. SM quits before the GUI shows up if I do that. It seems that we've already been applying class information from a object to another object. It prevents me from coming up with a patch. There is little information to determine whether the class information can be used on a object.

Comment 61

[Peter Van der Beken [:peterv]]

You shouldn't use the CI for a (DOM) object as the CI for another object, even if you're wrapping the first object. I'm working on a patch to actually prevent that. I don't understand what you're trying to do in comment 60, why are you comparing nsIClassInfo and nsISupports pointers? CI is usually implemented as a separate object, so they'll almost never be equal.

Comment 62

[Zane U. Ji]

(In reply to comment #61)
> You shouldn't use the CI for a (DOM) object as the CI for another object, even
> if you're wrapping the first object. I'm working on a patch to actually prevent
> that.

I'm glad to hear that.

> I don't understand what you're trying to do in comment 60, why are you
> comparing nsIClassInfo and nsISupports pointers?

To ensure that each object implements its own CI.

> CI is usually implemented as a
> separate object, so they'll almost never be equal.

You're right. I learnt that the hard way.

Comment 63

[Peter Van der Beken [:peterv]]

Attachment: v1

Throw when a JS component returns a native classinfo when QIed to nsIClassInfo.

Comment 64

[Johnny Stenback (:jst)]

Peter, this is ready to land now, right?

Comment 65

[Sheila Mooney]

I don't find @nsEventTargetSH::PreCreate(nsISupports*, JSContext*, JSObject*, JSObject**) on any recent version. The other signature - nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) only appear on 3.6 and 3.5. Resolving as works for me.