crash in js::InvokeKernel

VERIFIED FIXED in Firefox 15

Status

()

Core
XPConnect
--
critical
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Alice0775 White, Assigned: bholley)

Tracking

({crash, regression, reproducible})

15 Branch
mozilla16
x86
Windows 7
crash, regression, reproducible
Points:
---

Firefox Tracking Flags

(firefox15- verified, firefox16- verified)

Details

(crash signature, URL)

Attachments

(5 attachments)

(Reporter)

Description

5 years ago
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
(Reporter)

Comment 1

5 years ago
6. Repeat step 4 & 5 if necessary
OS: Windows NT → Windows 7
(Reporter)

Comment 2

5 years ago
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)
Keywords: regression, reproducible
(Reporter)

Updated

5 years ago
tracking-firefox15: --- → ?

Updated

5 years ago
Assignee: general → nobody
Blocks: 759788
Component: JavaScript Engine → Plug-ins
QA Contact: general → plugins
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.
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.

Updated

5 years ago
Crash Signature: [@ js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct)] → [@ js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) ]
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.
Component: Plug-ins → XPConnect
QA Contact: plugins → xpconnect
Created attachment 629822 [details]
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.
Created attachment 629823 [details]
stack DOMSVGTests::GetSystemLanguage
Created attachment 629824 [details]
stack DOMSVGTests::GetRequiredExtensions
Created attachment 629828 [details]
xpc::WrapperFactory::PrepareForWrapping

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?
No longer blocks: 759788
Bobby, can you look into this? Seems there's easy steps to reproduce here.
Assignee: nobody → bobbyholley+bmo
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.
Depends on: 764389
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.

Updated

5 years ago
tracking-firefox15: ? → +
tracking-firefox16: --- → +
(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.
tracking-firefox15: + → -
tracking-firefox16: + → -

Comment 18

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

Comment 19

5 years ago
Alice, can you confirm it's fixed in 15.0 Beta and 16.0 Aurora?
(Reporter)

Comment 20

5 years ago
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

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox15: --- → fixed
status-firefox16: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
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.
status-firefox15: fixed → verified
(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.
Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0b1
Status: RESOLVED → VERIFIED
status-firefox16: fixed → verified
QA Contact: paul.silaghi
You need to log in before you can comment on or make changes to this bug.