Closed Bug 765416 Opened 8 years ago Closed 4 years ago
weird stuff with cross fuzzing
11.58 KB, text/plain
4.08 KB, text/plain
12.33 KB, text/plain
4.40 KB, text/plain
1.27 KB, patch
|Details | Diff | Splinter Review|
6.13 KB, text/plain
2.03 KB, text/plain
21.60 KB, text/plain
+++ 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.
BTW, I still have the first crash in the debugger, let me know if you want any specific values.
Another JS assertion for the same test, not sure if it's related to the compartment issue.
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?
Also, if you do have the first crash - can you go up to the MoveWrapper frame, and do wrapper->mFlatJSObject->dump()?
I had do something else on this box so the debugger session was lost, sorry.
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.
can you do obj->dump() on frame 3?
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
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"
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.
I tried reproducing this for a while, but couldn't (though at one point I hit an assertion in the gc). :-(
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?
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.
(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?
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)
Bobby are you back from holiday?
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
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.
Disabling all plugins also helps avoiding unrelated crashes and assertions. Unchecking the pref "Open new windows in a new tab instead" might help too.
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.
The IsValid thing sounds like bug 781645.
Yeah, it's probably not worth looking at this before that bug is fixed.
Depends on: 781645
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
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).
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.
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
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
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)
I can still reproduce the "compartment mismatch" assertion after bug 790865 was fixed, using the URL in this bug.
On mozilla-central? I'm a little suspicious of bug 791896, but it's possible we'll have to debug cross_fuzz :(
mozilla-inbound, rev 13ae166abd45. I'll wait until that bug is fixed before testing again. Thanks.
Depends on: 791896
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.
Assertion failure: (obj2)->zone()->isGCMarking(), at js/src/gc/Marking.cpp:1339
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.
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
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.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.