Closed Bug 825401 Opened 8 years ago Closed 8 years ago

Abort when print-previewing bugzilla page in debug build w/ Ghostery add-on installed, with *** Compartment mismatch 0x2e7e8f0 vs. 0x3d39110 Assertion failure: compartment mismatched, at js/src/jscntxtinlines.h:268


(Core :: JavaScript Engine, defect)

Not set





(Reporter: dholbert, Assigned: mccr8)


(Keywords: assertion)

Same STR as bug 825380, but **using a debug build** (e.g. one of the mozilla-central-debug nightly builds from ):

>  1. Install Ghostery from
>    (Restart Firefox to complete the install)
>  2. Click "Skip wizard" on the ghostery config page
>  3. Log in to
>  4. Visit e.g. bug 700000
>  4. File | Print-preview
>    (on Linux or Windows; the Mac print-to-PDF preview probably doesn't
> trigger this)

ACTUAL RESULTS: Immediate abort on entering print preview, saying something like:
*** Compartment mismatch 0x2e7e8f0 vs. 0x3d39110
Assertion failure: compartment mismatched, at /builds/slave/m-cen-lnx64-dbg/build/js/src/jscntxtinlines.h:268

This started long before bug 825380's regression range -- for this debug-build abort, I get a regression range of:




...which includes some compartment-related changes. (notably " Bug 650353 - Implement Compartment-Per-Global in XPConnect"... not sure if that's the cause, but seems like a good candidate)
Presumably still the same as bug 821842.
Depends on: 821842
Assignee: general → continuation
Yeah, I think this is the same, but it is nice to know that this is probably a regression from CPG.
Stack is different than 821842. Instead of having init class it looks like: 

0   js::CompartmentChecker::fail(JSCompartment*, JSCompartment*) + 30
1   js::CompartmentChecker::check(JSObject*) + 83
2   JS_GetGlobalForObject(JSContext*, JSObject*) + 48
3   nsDocument::SetScriptGlobalObject(nsIScriptGlobalObject*) + 1106 (nsDocument.cpp:3872)
4   nsGlobalWindow::SetNewDocument(nsIDocument*, nsISupports*, bool) + 7837 (nsGlobalWindow.cpp:2073)
5   nsDocumentViewer::SetDocumentInternal(nsIDocument*, bool) + 500 (nsIDocument.h:1521)
6   nsDocumentViewer::SetDOMDocument(nsIDOMDocument*) + 119 (nsDocumentViewer.cpp:1734)
7   nsPrintObject::Init(nsIDocShell*, nsIDOMDocument*, bool) + 854 (nsPrintObject.cpp:94)
8   nsPrintEngine::DoCommonPrint(bool, nsIPrintSettings*, nsIWebProgressListener*, nsIDOMDocument*) + 1571 (nsPrintEngine.cpp:514)
9   nsPrintEngine::CommonPrint(bool, nsIPrintSettings*, nsIWebProgressListener*, nsIDOMDocument*) + 32 (nsPrintEngine.cpp:414)

...which is what the stack for the assert in bug 817342 looks like. I guess we could just be detecting the same problem at a different point.
This isn't fixed by my patch in bug 821842. I'm going to see what happens in a non-debug build with my patch to try to understand why we get such different behavior.
Looks like a dupe of 817342 to me. I was able to repro the crash, but with that bugs patch, I couldn't.
Closed: 8 years ago
No longer depends on: 821842
Resolution: --- → DUPLICATE
Duplicate of bug: 817342
Group: core-security
You need to log in before you can comment on or make changes to this bug.