760745 - crash in js::InvokeKernel

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Alice0775 White]

This bug was filed from the Socorro interface and is 
report bp-8da28eb8-43ac-44ea-a3ea-f0bec2120602 .
============================================================= 
Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/73783bf75c4c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120601030520

Reproducible: Always

Steps to Reproduce:

1. Start Browser with new profile
2. Open URL
3. Allow popup window and reload
4. Close tabs except  URL
5. Reload

Actual Results:  
  Browser crashes

Expected Results:  
  Should not

Comment 1

[Alice0775 White]

6. Repeat step 4 & 5 if necessary

Comment 2

[Alice0775 White]

Regression window:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f4981b5e1f7a&tochange=0aa7fc75cad5

Regressed by
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)

Comment 3

[Mats Palmgren (inactive)]

In a trunk debug build on Win7 with bug 759788 fixed:
Assertion failure: principals == JS_GetCompartmentPrincipals((js::GetContextCompartment(cx))), at
 caps/src/nsScriptSecurityManager.cpp:171

Backing out bug 759788 locally results in the exact same JS assertion.

Comment 4

[Mats Palmgren (inactive)]

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.

Comment 5

[Mats Palmgren (inactive)]

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.

Comment 6

[Mats Palmgren (inactive)]

Attachment: stack DOMSVGTests::GetRequiredFeatures

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.

Comment 7

[Mats Palmgren (inactive)]

Attachment: stack DOMSVGTests::GetSystemLanguage

Comment 8

[Mats Palmgren (inactive)]

Attachment: stack DOMSVGTests::GetRequiredExtensions

Comment 9

[Mats Palmgren (inactive)]

Attachment: xpc::WrapperFactory::PrepareForWrapping

This is the crash I get with rev 7377c9bd35c5:93641 (2012-05-09)

Comment 10

[Mats Palmgren (inactive)]

Attachment: XPCWrappedNative::GetLock() from xpc::WrapperFactory::PrepareForWrapping

This is the crash I get with rev eadef7d76892:93931 (2012-05-14)

Comment 11

[Mats Palmgren (inactive)]

This bug worries me.  jst, can you find an owner please?

Comment 12

[Johnny Stenback (:jst)]

Bobby, can you look into this? Seems there's easy steps to reproduce here.

Comment 13

[Bobby Holley (:bholley)]

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.

Comment 14

[Mats Palmgren (inactive)]

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.

Comment 15

[Alex Keybl [:akeybl]]

(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.

Comment 16

[Bobby Holley (:bholley)]

(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.

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

Untracking since this is resolved elsewhere.

Comment 18

[Scoobidiver (away)]

Alice, can you confirm it's fixed in 15.0 Bet

Comment 19

[Scoobidiver (away)]

Alice, can you confirm it's fixed in 15.0 Beta and 16.0 Aurora?

Comment 20

[Alice0775 White]

I can not reproduce the crash in 
http://hg.mozilla.org/releases/mozilla-beta/rev/8b97fc666642
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0 ID:20120710123126
and
http://hg.mozilla.org/releases/mozilla-aurora/rev/0add44c303d2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120717042008

Comment 21

[Paul Silaghi, QA [:pauly]]

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.

Comment 22

[(mostly gone) XtC4UaLL [:xtc4uall]]

(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
> (https://crash-stats.mozilla.com/report/index/bp-970ff458-a2ff-4b72-8f1e-
> dab842120731).

FWIW, filed Bug 779312 with proper Stack.

Comment 23

[Paul Silaghi, QA [:pauly]]

Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0b1