Closed
Bug 646184
Opened 15 years ago
Closed 15 years ago
Crash [@ nsGlobalWindow::GetLocalStorage] getting localStorage from removed frame
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla6
People
(Reporter: jruderman, Assigned: Ms2ger)
References
Details
(Keywords: crash, regression, testcase)
Crash Data
Attachments
(6 files)
|
281 bytes,
text/html
|
Details | |
|
1.33 KB,
text/plain
|
Details | |
|
1.74 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
|
2.61 KB,
patch
|
Details | Diff | Splinter Review | |
|
2.62 KB,
patch
|
Details | Diff | Splinter Review | |
|
11.05 KB,
text/plain; charset=UTF-8
|
Details |
First seen 2011-03-28 1:40pm. Might be a regression from the cedar merge :(
| Reporter | ||
Comment 1•15 years ago
|
||
| Reporter | ||
Comment 2•15 years ago
|
||
Oh I bet it's a regression from bug 639849.
Assignee: nobody → jruderman
Blocks: 639849
Comment 3•15 years ago
|
||
Hmm. Possible if someone nulls out only one of mDoc and mDocument. Ms2ger, can you look?
Comment 4•15 years ago
|
||
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?
| Reporter | ||
Updated•15 years ago
|
Assignee: jruderman → Ms2ger
| Reporter | ||
Comment 5•15 years ago
|
||
I must have accidentally clicked "Take" and not noticed that it made a change (rather than simply making a new field visible).
| Assignee | ||
Comment 6•15 years ago
|
||
In that case, this should fix it. Jesse, could you test?
Attachment #522812 -
Flags: review?(bzbarsky)
Comment 7•15 years ago
|
||
Comment on attachment 522812 [details] [diff] [review]
Patch v1: reinstate null checks.
r=me
Attachment #522812 -
Flags: review?(bzbarsky) → review+
| Assignee | ||
Comment 8•15 years ago
|
||
| Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Comment 9•15 years ago
|
||
Boris landed this on cedar, but I had to back it out because of oranges like this:
http://tinderbox.mozilla.org/showlog.cgi?log=Cedar/1301693776.1301694328.13610.gz
Original landing: http://hg.mozilla.org/projects/cedar/rev/649f50ed53ca
Backout: http://hg.mozilla.org/projects/cedar/rev/779e2ba9810b
Keywords: checkin-needed
| Assignee | ||
Comment 10•15 years ago
|
||
Unless someone has a better idea, I'll just have to annotate the test.
| Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Comment 11•15 years ago
|
||
(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.
Keywords: checkin-needed
| Reporter | ||
Comment 12•15 years ago
|
||
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.
Comment 14•15 years ago
|
||
(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.
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
Comment 18•15 years ago
|
||
(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.
| Assignee | ||
Comment 19•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
Looks like the assertion went away with today's tracemonkey merge (the current unexpected-pass orange).
Updated•14 years ago
|
Crash Signature: [@ nsGlobalWindow::GetLocalStorage]
Comment 24•14 years ago
|
||
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)
at /build/buildd/firefox-5.0+build1+nobinonly/build-tree/mozilla/dom/base/nsGlobalWindow.cpp:7987
regards,
david
Comment 25•14 years ago
|
||
Which fuzzer?
Comment 26•14 years ago
|
||
a private one ;)
Updated•7 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•