This bug was filed from the Socorro interface and is
report bp-8da28eb8-43ac-44ea-a3ea-f0bec2120602 .
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120601030520
Steps to Reproduce:
1. Start Browser with new profile
2. Open URL
3. Allow popup window and reload
4. Close tabs except URL
6. Repeat step 4 & 5 if necessary
0aa7fc75cad5 Mats Palmgren — Bug 759788 - Keep the plugin instance owner alive for the duration of DoStopPlugin so that everything gets cleaned up correctly, r=bsmedberg
Please add block 759788 (I do not have permission)
In a trunk debug build on Win7 with bug 759788 fixed:
Assertion failure: principals == JS_GetCompartmentPrincipals((js::GetContextCompartment(cx))), at
Backing out bug 759788 locally results in the exact same JS assertion.
In a trunk *Opt* build on Win7 with bug 759788 fixed I get the same stack
as Alice reported above (bp-8da28eb8-43ac-44ea-a3ea-f0bec2120602)
Backing out bug 759788 locally results in the same crash stack.
This doesn't appear to be a regression from bug 759788 to me.
I've built ten or so sample revisions from now back to early March and
while the top signature varies, my feeling is that it's the same
underlying bug. The bug appears to be unrelated to plugins - I can
reproduce the same crash stack using a profile with all plugins are
disabled. The common theme in my crash stacks are JS/compartment/
xpconnect/wrapper stuff leading up to some DOM access.
Investigating the assertion in comment 3 might be a good start.
Created attachment 629822 [details]
The stack I get in recent builds is trying to get SVG requiredfeatures
systemlanguage or requiredextensions. I'm not sure if this is just
an effect of how the test is designed or if there's something special
with these attributes.
I believe this is the same crash as reported, it's just that the Visual
debugger I'm using is better at figuring out the top stack frames than
the Socorro stack walker.
I have js::InvokeKernel consistently a few stack frames down.
Created attachment 629823 [details]
Created attachment 629824 [details]
Created attachment 629828 [details]
This is the crash I get with rev 7377c9bd35c5:93641 (2012-05-09)
Created attachment 629830 [details]
XPCWrappedNative::GetLock() from xpc::WrapperFactory::PrepareForWrapping
This is the crash I get with rev eadef7d76892:93931 (2012-05-14)
This bug worries me. jst, can you find an owner please?
Bobby, can you look into this? Seems there's easy steps to reproduce here.
So, I was able to reproduce the principal assertion, which turned into bug 764389. However, I wasn't able to reproduce the original crash. Once I land bug 764389, it would be helpful if someone could tell me if they can still reproduce any crashes here.
I can't reproduce the original assertion or crash in the latest
mozilla-inbound (with bug 764389 fixed) on Win7, but I got a
couple of compartment assertions which I filed as bug 765416.
(In reply to Bobby Holley (:bholley) from comment #13)
> So, I was able to reproduce the principal assertion, which turned into bug
> 764389. However, I wasn't able to reproduce the original crash. Once I land
> bug 764389, it would be helpful if someone could tell me if they can still
> reproduce any crashes here.
Should we consider uplifting bug 764389 to FF15 on beta? Or untrack this for release (since it isn't a top crasher or user pain point)? I could go either way, but would like to hear risk vs reward first.
(In reply to Alex Keybl [:akeybl] from comment #15)
> Should we consider uplifting bug 764389 to FF15 on beta? Or untrack this for
> release (since it isn't a top crasher or user pain point)? I could go either
> way, but would like to hear risk vs reward first.
Already landed on beta - see bug 764389 comment 16.
Untracking since this is resolved elsewhere.
Alice, can you confirm it's fixed in 15.0 Bet
Alice, can you confirm it's fixed in 15.0 Beta and 16.0 Aurora?
I can not reproduce the crash in
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0 ID:20120710123126
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120717042008
I see another crash signature on Nightly 2012-06-01 using the STR in comment 0 - mozjs.dll@0x53fdd (https://crash-stats.mozilla.com/report/index/bp-970ff458-a2ff-4b72-8f1e-dab842120731).
Anyway, I see no crashes on FF 15b2: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0
I guess it can marked as verified fixed.
(In reply to Paul Silaghi [QA] from comment #21)
> I see another crash signature on Nightly 2012-06-01 using the STR in comment
> 0 - mozjs.dll@0x53fdd
FWIW, filed Bug 779312 with proper Stack.
Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0b1