Closed Bug 542203 Opened 10 years ago Closed 8 years ago

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**) ]

Categories

(Core :: DOM: Events, defect, critical)

1.9.2 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: frank.zimmer, Assigned: peterv)

References

Details

(Keywords: crash, topcrash, Whiteboard: [crashkill][crashkill-thirdparty][topcrash #2 Fx3.6])

Crash Data

Attachments

(7 files)

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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 513305
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?
Duplicate of bug: compdir-lockdown
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.
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.
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.
Status: RESOLVED → REOPENED
Component: General → Extension Compatibility
Keywords: crash
QA Contact: general → extension.compatibility
Resolution: DUPLICATE → ---
Summary: FF crashes when using Google search and "escaeping" search entry → FF crashes when using Google search and "escaeping" search entry [caused by Firebug and YSlow]
Frank, what happens when you have enabled Firebug but not YSlow? Does it also prevent the crash?
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
Now that chofmann reopened the other bug, should we dupe against this one, once more?
(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.
John, you can find it here: https://addons.mozilla.org/de/firefox/addon/5369. It simply does some measurements for web page loading.
Status: REOPENED → NEW
Summary: FF crashes when using Google search and "escaeping" search entry [caused by Firebug and YSlow] → Crash in [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] when using Google search and "escaping" search entry [caused by Firebug and YSlow]
Duplicate of this bug: 542226
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
Summary: Crash in [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] when using Google search and "escaping" search entry [caused by Firebug and YSlow] → Crash in [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] when using Google search and "escaping" search entry [caused by YSlow]
Frank does it work for you with version 2.0.6 now? It's already available (https://addons.mozilla.org/de/firefox/addon/5369)
Hi,

i have recently updated YSlow to 2.0.6 and until now no crash is happening again.
Seems stable now.
Good to hear that. Looks like it has been fixed on their end. Let's resolve this bug.
Status: NEW → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → INVALID
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.
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?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(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.
Did anyone reach out to YSlow?  They already updated the extension so what's to block?
(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.
http://developer.yahoo.com/yslow/help/
under Installing YSlow says
YSlow needs Firebug to run.
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.
Attached file yslow-2.0.5.xpi
I got this from the YSlow developers.
All JS, no components
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.
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.
Status: REOPENED → NEW
Summary: Crash in [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] when using Google search and "escaping" search entry [caused by YSlow] → Crash in [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] when using Google search and "escaping" search entry [caused by Firebug and YSlow]
Attached file 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
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.
Keywords: topcrash
Whiteboard: [crashkill][topcrash #2 Fx3.6]
Whiteboard: [crashkill][topcrash #2 Fx3.6] → [crashkill][crashkill-thirdparty][topcrash #2 Fx3.6]
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
(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.
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>yslow@yahoo-inc.com</td>
	                    <td>2.0.5</td>

http://crash-stats.mozilla.com/report/index/ff11b938-6a41-4402-a642-056ab2100127
	                    <td>yslow@yahoo-inc.com</td>
	                    <td>2.0.5</td>

http://crash-stats.mozilla.com/report/index/fecc414e-ad48-4e83-84d4-af0062100127
	                    <td>yslow@yahoo-inc.com</td>
	                    <td>2.0.5</td>

http://crash-stats.mozilla.com/report/index/fe9ad522-ccc5-41ad-8515-369042100127
	                    <td>yslow@yahoo-inc.com</td>
	                    <td>2.0.5</td>

http://crash-stats.mozilla.com/report/index/fdeb143a-c1be-4ecd-bedd-5fd652100127
	                    <td>yslow@yahoo-inc.com</td>
	                    <td>2.0.5</td>
a few reports have

http://crash-stats.mozilla.com/report/index/ff38bb11-b2da-4aec-ba9f-f4a262100127
	                    <td>yslow@yahoo-inc.com</td>
	                    <td>2.0.5</td>
	                    <td>firebug@software.joehewitt.com</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>yslow@yahoo-inc.com</td>
	                    <td>2.0.5</td>
	                    <td>firebug@software.joehewitt.com</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.
(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.
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.
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.
Component: Extension Compatibility → DOM: Events
Product: Firefox → Core
QA Contact: extension.compatibility → events
Version: 3.6 Branch → 1.9.2 Branch
Attached file 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.
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.
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.
(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.
Duplicate of this bug: 503946
Summary: Crash in [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] when using Google search and "escaping" search entry [caused by Firebug and YSlow] → Crash in [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] when using Google search and "escaping" search entry [triggered by Firebug and YSlow]
Attached file 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.
peterv, any comments to comment 43?
You changed the code to require nsXHREventTarget.
The class type shouldn't be hard coded. In yslow case, it is nsXPTCStubBase rather than nsXHREventTarget.
Sorry if you're talking about nsXHREventTarget::GetParentObject.
(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.
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.
Duplicate of this bug: 543646
Summary: Crash in [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] when using Google search and "escaping" search entry [triggered by Firebug and YSlow] → 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**) ]
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.
No. Null is acceptable. That yslow patch is just for demonstration.
wonder if  Bug 544640 is also a dup/variant.  that signature is rising fast.
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?
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
it looks like app.update.timer is set to 600000 miliseconds or 10 minutes as the default setting
The network layer monitoring available in the platform and used by Firebug (and YSlow) is global. It is triggered by the update network events.
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.
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.
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.
(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.
Attached patch v1Splinter Review
Throw when a JS component returns a native classinfo when QIed to nsIClassInfo.
Assignee: nobody → peterv
Status: NEW → ASSIGNED
Attachment #432640 - Flags: review?(jst)
Attachment #432640 - Flags: review?(jst) → review+
Peter, this is ready to land now, right?
Crash Signature: [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] [@nsEventTargetSH::PreCreate(nsISupports*, JSContext*, JSObject*, JSObject**) ]
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.
Status: ASSIGNED → RESOLVED
Crash Signature: [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] [@nsEventTargetSH::PreCreate(nsISupports*, JSContext*, JSObject*, JSObject**) ] → [@ nsXHREventTarget::GetParentObject(nsIScriptGlobalObject**) ] [@nsEventTargetSH::PreCreate(nsISupports*, JSContext*, JSObject*, JSObject**) ]
Closed: 10 years ago8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.