609793 - Crash in XPConnect code caused by a seemingly benign code change ([@ XPC_WN_CallMethod], [@ XPC_WN_GetterSetter])

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[(no longer active)]

Attachment: gdb log

This patches causes intermittent crashes in browser-chrome tests:

http://hg.mozilla.org/mozilla-central/rev/119ed9cbd3c6

Here are the crash logs:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288907394.1288908638.9885.gz&fulltext=1
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288909347.1288910085.18324.gz&fulltext=1
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288908667.1288910403.19870.gz&fulltext=1
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288911180.1288912207.28675.gz&fulltext=1
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288905988.1288908421.8895.gz&fulltext=1
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288910208.1288911386.24890.gz&fulltext=1
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288906850.1288908627.9851.gz&fulltext=1

I've managed to reproduce this crash locally once, and DumpJSStack() pointed me to somewhere around here on the js stack:

<http://hg.mozilla.org/mozilla-central/annotate/c0dbdafa583c/browser/base/content/browser.js#l7431>

But I'm not certain about this at all, as I've only been able to reproduce this locally once; I'm attaching the gdb log from that one time here.

Also, it seems like the "XPConnect is being called on a scope without a 'Components' property" assertion always precedes this crash.

Can someone investigate this, please?

Comment 1

[(no longer active)]

I looked at the preprocessed browser.js file, and the crash happens when we try to call setTimeout.

Comment 2

[Josh Matthews [:jdm]]

Attachment: Test changes

With this patch applied, if I run |TEST_PATH=toolkit/components/satchel/test/ make -C ff-dbg/ mochitest-plain| and press the Run Tests link while the tests are in flight, the console gets spammed with this error and Firefox sometimes crashes.  Without the patch applied, I can't reproduce.

Comment 3

[(no longer active)]

I posted attachment 490446 [details] [diff] [review] to remove the setTimeout call I mentioned in comment 1.  This might need to block 2.0 (at least for investigation) because a crash which happens because of a setTimeout call is scary...

Comment 4

[Johnny Stenback (:jst)]

Based on Ehsan's debugging session (attachment), this looks like the JS engine is handing a dead object to XPConnect. Luke agreed that there's no GC hazard in this code that could cause obj to be deleted in XPC_WN_CallMethod(), which suggests to me that obj is already dead when XPConnect gets it. Over to the JS engine.

Comment 5

[(no longer active)]

Here's some crash logs from the landing of bug 607482 (with the part 2 patch on that bug):

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1290122046.1290123351.23816.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1290121705.1290123252.22834.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1290121199.1290122427.18768.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1290120938.1290122356.18267.gz

I suspect that something in the recent tracemonkey merge has rendered the workaround in the part 2 patch on that bug ineffective.

Comment 6

[(no longer active)]

There are some crashes on crash-stats with XPC_WN_GetterSetter in their signature (which is where the crash happens now on mozilla-central.

Comment 7

[(no longer active)]

And the crash stats link that I meant to paste is http://bit.ly/aFjfSn.

Comment 8

[Marcia Knous [:marcia]]

Roughly 185 Windows crashes in the last week on the trunk in the @ XPC_WN_CallMethod signature (or variants thereof). For @ XPC_WN_GetterSetter there are roughly 200 crashes in the last week on the trunk with several variant signatures as well. I listed the variants below:

XPC_WN_GetterSetter(JSContext*, JSObject*, unsigned int, int*, int*)	
XPC_WN_GetterSetter(JSContext*, unsigned int, unsigned __int64*)
XPC_WN_GetterSetter(JSContext*, JSObject*, unsigned int, long*, long*)
XPC_WN_GetterSetter(JSContext*, JSObject*, unsigned int, unsigned __int64*, unsigned __int64*)
@0x0 | XPC_WN_GetterSetter(JSContext*, unsigned int, unsigned __int64*)	
@0x0 | XPC_WN_GetterSetter(JSContext*, JSObject*, unsigned int, int*, int*)

XPC_WN_CallMethod(JSContext*, JSObject*, unsigned int, int*, int*)	
XPC_WN_CallMethod(JSContext*, unsigned int, unsigned __int64*)
@0x0 | XPC_WN_CallMethod(JSContext*, JSObject*, unsigned int, int*, int*)	
XPC_WN_CallMethod(JSContext*, JSObject*, unsigned int, long*, long*)	
@0x0 | XPC_WN_CallMethod(JSContext*, unsigned int, unsigned __int64*)

Comment 9

[Johnny Stenback (:jst)]

We've fixed bugs in the past where we could end up with an outer window being collected too early, after we've cleared its scope (bug 606709). This sounds very related. Ehsan, do you think there's a faster way to move forward here than to attempt to re-land the patch that triggered this intermittent crash?

Given the lack of reliable ways to reproduce this, I don't think we can block on this.

Comment 10

[(no longer active)]

(In reply to comment #9)
> We've fixed bugs in the past where we could end up with an outer window being
> collected too early, after we've cleared its scope (bug 606709). This sounds
> very related. Ehsan, do you think there's a faster way to move forward here
> than to attempt to re-land the patch that triggered this intermittent crash?

Actually, the patch which triggered this landed a while ago (bug 607482), so it might have been something which is either fixed, or is no longer triggered by that patch.  I'd WFM this if I _knew_ that the former case is true, but I'm not sure.

The only way that I can think of to investigate this is to update to a cset around the time when when bug 607482 landed for the first or second time, apply the patch, and run under the debugger.

> Given the lack of reliable ways to reproduce this, I don't think we can block
> on this.

Totally agreed!

Comment 11

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.