Closed Bug 760745 Opened 10 years ago Closed 10 years ago
crash in js::Invoke
7.29 KB, text/plain
8.26 KB, text/plain
6.67 KB, text/plain
7.39 KB, text/plain
7.71 KB, text/plain
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
6. Repeat step 4 & 5 if necessary
OS: Windows NT → Windows 7
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)
Assignee: general → nobody
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.
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
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.
This is the crash I get with rev 7377c9bd35c5:93641 (2012-05-09)
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.
(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.
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 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
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 > (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
You need to log in before you can comment on or make changes to this bug.