crash in nsContentUtils::SubjectPrincipal()

VERIFIED FIXED in Firefox 32

Status

()

defect
--
critical
VERIFIED FIXED
5 years ago
5 months ago

People

(Reporter: jbecerra, Assigned: bobbyholley)

Tracking

({crash})

32 Branch
mozilla32
x86
Windows NT
Points:
---

Firefox Tracking Flags

(firefox32 verified)

Details

(crash signature)

Attachments

(1 attachment)

This bug was filed from the Socorro interface and is 
report bp-813fad95-dd6a-494b-8c77-941da2140529.
=============================================================

This is a new signature that first appeared on 5/16 and it is now in the top 20 crashers for nightly. It's mostly happening on Win7 (almost 50%), and then evenly among Win8 and Win8.1.

There are no comments in the reports.

More reports can be found here: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=nsContentUtils%3A%3ASubjectPrincipal%28%29

0 	xul.dll 	nsContentUtils::SubjectPrincipal() 	content/base/src/nsContentUtils.cpp
1 	xul.dll 	nsContentUtils::IsCallerChrome() 	content/base/src/nsContentUtils.cpp
2 	xul.dll 	XPCJSRuntime::InterruptCallback(JSContext *) 	js/xpconnect/src/XPCJSRuntime.cpp
3 	mozjs.dll 	js::InvokeInterruptCallback(JSContext *) 	js/src/jscntxt.cpp
4 	mozjs.dll 	js::CheckForInterrupt(JSContext *) 	js/src/jscntxt.h
5 	mozjs.dll 	Interpret 	js/src/vm/Interpreter.cpp
6 	mozjs.dll 	js::RunScript(JSContext *,js::RunState &) 	js/src/vm/Interpreter.cpp
7 	mozjs.dll 	js::Invoke(JSContext *,JS::CallArgs,js::MaybeConstruct) 	js/src/vm/Interpreter.cpp
8 	mozjs.dll 	Interpret 	js/src/vm/Interpreter.cpp
9 	mozjs.dll 	js::RunScript(JSContext *,js::RunState &) 	js/src/vm/Interpreter.cpp
10 	mozjs.dll 	js::ExecuteKernel(JSContext *,JS::Handle<JSScript *>,JSObject &,JS::Value const &,js::ExecuteType,js::AbstractFramePtr,JS::Value *) 	js/src/vm/Interpreter.cpp
11 	mozjs.dll 	js::Execute(JSContext *,JS::Handle<JSScript *>,JSObject &,JS::Value *) 	js/src/vm/Interpreter.cpp
12 	mozjs.dll 	Evaluate 	js/src/jsapi.cpp
13 	mozjs.dll 	Evaluate 	js/src/jsapi.cpp
14 	mozjs.dll 	JS::Evaluate(JSContext *,JS::Handle<JSObject *>,JS::ReadOnlyCompileOptions const &,char const *,unsigned int,JS::MutableHandle<JS::Value>) 	js/src/jsapi.cpp
15 	mozjs.dll 	JSRuntime::initSelfHosting(JSContext *) 	js/src/vm/SelfHosting.cpp
16 	mozjs.dll 	js::NewContext(JSRuntime *,unsigned int) 	js/src/jscntxt.cpp
17 	mozjs.dll 	JS_NewContext(JSRuntime *,unsigned int) 	js/src/jsapi.cpp
18 	xul.dll 	XPCJSContextStack::InitSafeJSContext() 	js/xpconnect/src/XPCJSContextStack.cpp
19 	xul.dll 	Initialize() 	layout/build/nsLayoutModule.cpp
20 	xul.dll 	nsFactoryEntry::GetFactory() 	xpcom/components/nsComponentManager.cpp
21 	xul.dll 	nsComponentManagerImpl::CreateInstanceByContractID(char const *,nsISupports *,nsID const &,void * *) 	xpcom/components/nsComponentManager.cpp
22 	xul.dll 	nsComponentManagerImpl::GetServiceByContractID(char const *,nsID const &,void * *) 	xpcom/components/nsComponentManager.cpp
23 	xul.dll 	nsCOMPtr_base::assign_from_gs_contractid(nsGetServiceByContractID,nsID const &) 	xpcom/glue/nsCOMPtr.cpp
24 	xul.dll 	nsCOMPtr<nsISupports>::nsCOMPtr<nsISupports>(nsGetServiceByContractID) 	xpcom/glue/nsCOMPtr.h
25 	xul.dll 	NS_InitXPCOM2 	xpcom/build/nsXPComInit.cpp
26 	xul.dll 	ScopedXPCOMStartup::Initialize() 	toolkit/xre/nsAppRunner.cpp
27 	xul.dll 	XREMain::XRE_main(int,char * * const,nsXREAppData const *) 	toolkit/xre/nsAppRunner.cpp
28 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp
29 	firefox.exe 	do_main 	browser/app/nsBrowserApp.cpp
30 	firefox.exe 	NS_internal_main(int,char * *) 	browser/app/nsBrowserApp.cpp
31 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp
32 	firefox.exe 	__tmainCRTStartup 	f:/dd/vctools/crt_bld/self_x86/crt/src/crtexe.c:552
33 	kernel32.dll 	BaseThreadInitThunk 	
34 	ntdll.dll 	__RtlUserThreadStart 	
35 	ntdll.dll 	_RtlUserThreadStart
'tis a null-deref.  We're early in startup, initializing the safe JSContext and all.  Presumably nsContentUtils::sXPConnect is still null at this point?
Component: JavaScript Engine → DOM
Flags: needinfo?(bobbyholley)
Yes, we're hitting the slow script dialog here before the relevant state is set up. This seems kind of odd, but maybe these machines are just really overloaded? I'll attach a patch.
Flags: needinfo?(bobbyholley)
Assignee: nobody → bobbyholley
Comment on attachment 8435123 [details] [diff] [review]
Bail out of InterruptCallback if we're too early in startup. v1

r=me
Attachment #8435123 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/7792ac87eb27
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Looking in Socorro [1], there  are now only 2 crashes with this signature over the past 28 days (both on 32.0 Beta 5, BuildID: 20140807212602, one on Win XP and one on Win 7). Given this, I'll close this as Verified.

[1] - https://crash-stats.mozilla.com/report/list?signature=nsContentUtils%3A%3ASubjectPrincipal%28%29&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2014-08-18+15%3A00%3A00&range_value=4#tab-reports
Status: RESOLVED → VERIFIED
Keywords: verifyme
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.