Closed
Bug 765416
Opened 13 years ago
Closed 9 years ago
weird stuff with cross fuzzing
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
firefox15 | --- | affected |
firefox16 | --- | affected |
firefox17 | --- | affected |
firefox-esr10 | --- | unaffected |
People
(Reporter: MatsPalmgren_bugz, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: crash, regression, sec-moderate)
Attachments
(8 files)
+++ This bug was initially created as a clone of Bug #760745 +++
Using a local mozilla-inbound debug build I get a couple
of compartment assertion when running cross_fuzz.
1. Start Browser with new profile
2. Uncheck "block popup windows" pref (not sure if this is needed)
3. Open URL
4. every now and then, manually focus the tab opened in 3,
close popup windows, close other tabs. (it seems the test
runs slowly when the original tab is in the background)
ACTUAL RESULTS
###!!! ASSERTION: Weird scope returned: 'betterScope == newScope', file d:/moz/inbound/js/xpconnect/src/nsXPConnect.cpp, line 1637
*** Compartment mismatch 04D630A8 vs. 0BF53A98
Assertion failure: compartment mismatched, at d:\moz\inbound\js\src\jscntxtinlines.h:237
It might be a regression in the last week or so - I didn't
get these compartment assertions when testing bug 760745
a week ago.
Reporter | ||
Comment 1•13 years ago
|
||
Reporter | ||
Comment 2•13 years ago
|
||
BTW, I still have the first crash in the debugger, let me know if you want
any specific values.
Reporter | ||
Comment 3•13 years ago
|
||
Another JS assertion for the same test, not sure if it's related
to the compartment issue.
Comment 4•12 years ago
|
||
Let's make this s-s for now.
I wonder if this is the same as bug 732870. Can you reproduce it with that patch?
Group: core-security
Comment 5•12 years ago
|
||
Also, if you do have the first crash - can you go up to the MoveWrapper frame, and do wrapper->mFlatJSObject->dump()?
Reporter | ||
Comment 6•12 years ago
|
||
I had do something else on this box so the debugger session was lost, sorry.
Reporter | ||
Comment 7•12 years ago
|
||
This is the latest mozilla-inbound with the patch in bug 732870 applied.
I'll leave the debugger open, let me know if you want any values.
Comment 8•12 years ago
|
||
can you do obj->dump() on frame 3?
Reporter | ||
Comment 9•12 years ago
|
||
object 0BB2C650
class 7077FE08 Proxy
flags:
proto <Proxy object at 0BB2C600>
parent <Window object at 0BB14040>
not native
slots:
0 (reserved) = 9,32335e-315
1 (reserved) = <function eval at 10543480>
2 (reserved) = undefined
3 (reserved) = undefined
4 (reserved) = <function eval at 10543480>
5 (reserved) = undefined
Comment 10•12 years ago
|
||
js::UnwrapObject(obj)->dump()?
Reporter | ||
Comment 11•12 years ago
|
||
object 10543480
class 7077DF38 Function
flags:
proto <unnamed function (:0) at 10543020>
parent <Window object at 105E6040>
properties:
((Shape *) 117CD8B0) readonly permanent JSString* (04612800) = jschar * (04612808) = "name"
: slot 0 = JSString* (04612660) = jschar * (04612668) = "eval"
Comment 12•12 years ago
|
||
Ok, I'll try to take a look at it sometime soon. I'm generally loath to debug crossfuzz testcases because they're such a pain to reproduce. But I'll give it a once I dig myself out from under my existing pile of security bugs.
mccr8 might also be interested in looking at this if he has the cycles.
Updated•12 years ago
|
Updated•12 years ago
|
Assignee: nobody → bobbyholley+bmo
Updated•12 years ago
|
Keywords: sec-critical
Updated•12 years ago
|
Comment 13•12 years ago
|
||
I tried reproducing this for a while, but couldn't (though at one point I hit an assertion in the gc). :-(
Comment 14•12 years ago
|
||
Jesse: can you take a look at this and see if your fuzzer's incorporation of cross_fuzz techniques might hit this error? Or if not see if there are some tweaks we need?
Keywords: reproducible → testcase-wanted
Comment 15•12 years ago
|
||
This might be a dup of bug 732870. Even if it's not, I wouldn't start worrying unless this bug persists after bug 766430, bug 767273, and bug 772215 are fixed.
Comment 16•12 years ago
|
||
(In reply to Jesse Ruderman from comment #15)
> This might be a dup of bug 732870. Even if it's not, I wouldn't start
> worrying unless this bug persists after bug 766430, bug 767273, and bug
> 772215 are fixed.
Are we seeing any more assertions in FF15 after bug 732870 landed?
Reporter | ||
Comment 17•12 years ago
|
||
Yes, the fatal "compartment mismatched" assertion is still easy to
reproduce. The non-fatal "Weird scope" assertion that preceded it
seems to be gone now. (mozilla-inbound debug build on Win7)
Updated•12 years ago
|
Comment 18•12 years ago
|
||
Bobby are you back from holiday?
Comment 19•12 years ago
|
||
I just spent another half hour messing around with the testcase (on osx 10.7). At least for me, it's really erratic. I once managed to reproduce the compartment mismatch, but couldn't reproduce it in a debugger (though I managed to reproduce a number of other assertions/aborts from all over the place - svg etc).
Given that I only managed to reproduce the issue once in that span of time, and given that fixing/verifying these kinds of bugs generally requires reproducing them dozens of times, the path ahead doesn't seem tractable enough to make this a priority for me. I'm unassigning myself from this bug to draw attention to the fact that I consider myself blocked here. Happy to talk about this more on IRC etc.
Assignee: bobbyholley+bmo → nobody
Reporter | ||
Comment 20•12 years ago
|
||
Sorry if I didn't mention it, but XPCOM_DEBUG_BREAK=warn is assumed
since you wont get very far without that.
Also, disabling this fatal SVG assertion helps.
Reporter | ||
Comment 21•12 years ago
|
||
Disabling all plugins also helps avoiding unrelated crashes and
assertions. Unchecking the pref "Open new windows in a new tab
instead" might help too.
Reporter | ||
Comment 22•12 years ago
|
||
I ran the test again and now I either get this crash in
XPCWrappedNative::IsValid with a null 'this', or a hang
somewhere in JS GC.
Comment 23•12 years ago
|
||
The IsValid thing sounds like bug 781645.
Reporter | ||
Comment 24•12 years ago
|
||
Yeah, it's probably not worth looking at this before that bug is fixed.
Depends on: 781645
Comment 25•12 years ago
|
||
Andrew, mind sitting on owning this one at least while you are active bug 781645 (see what happens when you miss critsmash ;) )
Assignee: nobody → continuation
Comment 26•12 years ago
|
||
lowering severity because the original symptoms are gone and it's been hard to reproduce even in affected versions. There may be a sec-critical bug hiding in here but we can better spend our time fixing other sec-criticals that are easier to debug and reproduce (and potentially, easier to be found by bad guys).
status-firefox-esr10:
--- → unaffected
Comment 27•12 years ago
|
||
Mats, do you still see any problems with this? I tried running it and didn't hit anything fatal. Well, one time it hung somewhere in JS land, but I'm not sure what that was about.
Reporter | ||
Comment 28•12 years ago
|
||
I tested this a couple of day ago and got bug 790649.
I can't tell for sure if the original problem is gone before
the blocking bugs are resolved. I agree with dveditz that
this bug is low priority until then.
Depends on: 790649
Comment 29•12 years ago
|
||
I'm going to unassign myself until this is more actionable, and I'm updating the summary to reflect the current state of affairs for this bug.
Assignee: continuation → nobody
Summary: ASSERTION: Weird scope returned: 'betterScope == newScope', followed by Assertion failure: compartment mismatched → weird stuff with cross fuzzing
Reporter | ||
Comment 30•12 years ago
|
||
The "compartment mismatch" assertion still occurs for this URL.
This is the DumpJSStack() output when that occurred.
(with the patch in bug 790649 to avoid hitting that crash)
Reporter | ||
Comment 31•12 years ago
|
||
I can still reproduce the "compartment mismatch" assertion after bug 790865
was fixed, using the URL in this bug.
Comment 32•12 years ago
|
||
On mozilla-central?
I'm a little suspicious of bug 791896, but it's possible we'll have to debug cross_fuzz :(
Reporter | ||
Comment 33•12 years ago
|
||
mozilla-inbound, rev 13ae166abd45. I'll wait until that bug is fixed
before testing again. Thanks.
Depends on: 791896
Comment 34•12 years ago
|
||
Mats, does this reproduce for you now? We've added a bunch more compartment checking, and fixed some things, so this may be fixed, or we may at least get a better stack.
Reporter | ||
Comment 35•12 years ago
|
||
Assertion failure: (obj2)->zone()->isGCMarking(), at js/src/gc/Marking.cpp:1339
Updated•12 years ago
|
Assignee: nobody → continuation
Reporter | ||
Comment 36•12 years ago
|
||
I got the "Assertion failure: (obj2)->zone()->isGCMarking()" again just now.
(I'll leave it in the debugger for a while in case you want any values from it).
Other than that, I haven't seen any issues on the JS/XPCOM/DOM front.
Comment 37•11 years ago
|
||
Bug 825326 fixes the same assertion, but was fixed before this. Anyways, this is a JS assertion, so I'll move it over there...
Assignee: continuation → general
Component: XPConnect → JavaScript Engine
Updated•11 years ago
|
Group: javascript-core-security
Updated•10 years ago
|
Group: javascript-core-security
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Updated•9 years ago
|
Group: core-security → javascript-core-security
Updated•9 years ago
|
Keywords: regressionwindow-wanted
Comment 38•9 years ago
|
||
None of the asserts in this bug exist anymore AFAICT. Closing this as incomplete at this point since it seems unlikely that anything useful is going to come out of this bug at this point. Feel free to reopen if there's something to do here still.
Updated•9 years ago
|
Group: javascript-core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•