Created attachment 522774 [details]
testcase (crashes Firefox when loaded)
First seen 2011-03-28 1:40pm. Might be a regression from the cedar merge :(
Created attachment 522776 [details]
Oh I bet it's a regression from bug 639849.
Hmm. Possible if someone nulls out only one of mDoc and mDocument. Ms2ger, can you look?
Oh, wait. They're probably just both null and the code lost the null-check.
Jesse, are you patching? If not, please reassign to Ms2ger?
I must have accidentally clicked "Take" and not noticed that it made a change (rather than simply making a new field visible).
Created attachment 522812 [details] [diff] [review]
Patch v1: reinstate null checks.
In that case, this should fix it. Jesse, could you test?
Comment on attachment 522812 [details] [diff] [review]
Patch v1: reinstate null checks.
Created attachment 522941 [details] [diff] [review]
Patch for checkin.
Boris landed this on cedar, but I had to back it out because of oranges like this:
Original landing: http://hg.mozilla.org/projects/cedar/rev/649f50ed53ca
Created attachment 523768 [details] [diff] [review]
Unless someone has a better idea, I'll just have to annotate the test.
(In reply to comment #10)
> Created attachment 523768 [details] [diff] [review]
> Annotated assertion.
> Unless someone has a better idea, I'll just have to annotate the test.
Seems like a bad idea to me. We should understand the assertion. CCing some people who might know stuff about xpconnect.
The orange is the new test hitting the assertion
###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property! (stack and details follow): 'Error', file /builds/slave/ced-osx64-dbg/build/js/src/xpconnect/src/xpcwrappednativescope.cpp, line 761
dbaron can probably tell us which existing bug report covers it ;)
I think we should check this in ... the XPConnect assertion happens quite often on many different things including session restore.
(In reply to comment #13)
> I think we should check this in ... the XPConnect assertion happens quite often
> on many different things including session restore.
I would be fine with us landing this with a assertion annotations _if_ we knew that the triggered assertion is an instance of an existing bug. So far, I've not seen anything which suggests this is true.
Ehsan and I chatted on IRC a bit about this. Does the assertion happen before and after the fix with the testcase? If the assertion is added by the fix, then we need to figure it out.
Created attachment 526635 [details]
details from log in comment 9
I think the assertion:
* is not caused by the patch
* might or might not have the same underlying cause as bug 631289
* is not related to any of the existing no-Components assertion bugs
(In reply to comment #17)
> I think the assertion:
> * is not caused by the patch
> * might or might not have the same underlying cause as bug 631289
> * is not related to any of the existing no-Components assertion bugs
In that case, I'd be fine with this patch landing if you file a new bug for the assertion, and add the bug # to the reftest manifest annotating the assertion as a comment.
Looks like the assertion went away with today's tracemonkey merge (the current unexpected-pass orange).
Still crashes in Fennec5.0 beta.
*** Bug 670576 has been marked as a duplicate of this bug. ***
*** Bug 659904 has been marked as a duplicate of this bug. ***
just stumble upon today with my fuzzer using latest ubuntu linux and firefox 5.0,
here an extract from gdb
Program received signal SIGSEGV, Segmentation fault.
0xb7115955 in nsGlobalWindow::GetLocalStorage (this=0xa19ec0b0, aLocalStorage=0xbfffde4c)
a private one ;)