1326539 - Startup crash in nsXPConnect::InitStatics

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P3)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-d26aa77d-4acb-4693-aa13-3373b2161231.
=============================================================
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsXPConnect::InitStatics() 	js/xpconnect/src/nsXPConnect.cpp:127
1 	xul.dll 	nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) 	xpcom/components/nsComponentManager.cpp:1200
2 	xul.dll 	nsComponentManagerImpl::GetServiceByContractID(char const*, nsID const&, void**) 	xpcom/components/nsComponentManager.cpp:1559
3 	mozglue.dll 	mozglue.dll@0x294f 	
4 		@0x0 	
5 	xul.dll 	nsTHashtable<nsBaseHashtableET<nsCStringHashKey, nsFactoryEntry*> >::s_HashKey(void const*) 	obj-firefox/dist/include/nsTHashtable.h:374
6 	ntdll.dll 	RtlAllocateMemoryZone 	
7 	combase.dll 	TLSGrowMap()

this cross-platform startup crash signature has been around for a while but has visibly risen in volume in firefox 50 and subsequent builds. 
most of the reports are annotated with MOZ_CRASH(InitSelfHostedCode failed).

Correlations for Firefox Release
(100.0% in signature vs 02.35% overall) reason = EXCEPTION_BREAKPOINT
(77.78% in signature vs 00.00% overall) moz_crash_reason = MOZ_CRASH(InitSelfHostedCode failed)

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The line |MOZ_CRASH(InitSelfHostedCode failed)| was added in bug 767938. Could you please take a look at this significant crash? Thanks.

Comment 2

[Andrew McCreight [:mccr8]]

This is crashing because InitSelfHostedCode is returning false. It looks like this code changed in bug 1279295, which landed in 50. Jan, could you look into this? Thanks.

Comment 3

[Jan de Mooij [:jandem]]

(In reply to Andrew McCreight [:mccr8] from comment #2)
> This is crashing because InitSelfHostedCode is returning false. It looks
> like this code changed in bug 1279295, which landed in 50. Jan, could you
> look into this? Thanks.

Before that bug, we did this in JS_NewContext and if that failed we crashed in XPCJSContext::InitSafeJSContext: https://crash-stats.mozilla.com/signature/?signature=XPCJSContextStack%3A%3AInitSafeJSContext

So I don't think this is anything new, just a signature change.

Comment 4

[Jan de Mooij [:jandem]]

Some of these reports look like OOM crashes, but this one looks like it had enough memory:

https://crash-stats.mozilla.com/report/index/bab32e9b-f860-433c-a6fb-f3fbc2170101

Have we seen these startup OOM crashes in other parts of the browser?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> The line |MOZ_CRASH(InitSelfHostedCode failed)| was added in bug 767938.

No, it wasn't.  It was just moved from XPCJSContextStack::InitSafeJSContext (or more precisely, InitSafeJSContext was inlined into nsXPConnect::InitStatics).

Is this crash happening more than the old signatures matching it used to happen?

I wonder whether it's worth putting MOZ_CRASHes in places deeper into JS::InitSelfHostedCode where it would return false, so we have some idea of which of those returns is being taken.

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #5)
> > The line |MOZ_CRASH(InitSelfHostedCode failed)| was added in bug 767938.
> 
> No, it wasn't.  It was just moved from XPCJSContextStack::InitSafeJSContext
> (or more precisely, InitSafeJSContext was inlined into
> nsXPConnect::InitStatics).
> 
> Is this crash happening more than the old signatures matching it used to
> happen?
> 

Good point!
Here's the report for the signature XPCJSContextStack::InitSafeJSContext for the past 6 months https://crash-stats.mozilla.com/signature/?signature=XPCJSContextStack%3A%3AInitSafeJSContext&date=%3E%3D2016-07-04T08%3A57%3A50.000Z&date=%3C2017-01-04T08%3A57%3A50.000Z#graphs

this is the one for nsXPConnect::InitStatics https://crash-stats.mozilla.com/signature/?signature=nsXPConnect%3A%3AInitStatics&date=%3E%3D2016-07-04T08%3A57%3A36.000Z&date=%3C2017-01-04T08%3A57%3A36.000Z#graphs

Then, no, according to the graphs, this crash doesn't look happening more than the old one.

Comment 7

[Julien Cristau [:jcristau]]

Too late for firefox 52, mass-wontfix.

Comment 8

[Wayne Mery (:wsmwk)]

bp-ab50addb-d10c-4e06-b9ac-1f6560180613 (solargrid) TB52.5.2
bp-e6f1f3a5-ad9e-43ab-a537-13fb70180720 (dstraub) TB52.9.1

Many of these thunderbird users also have startup crash signatures of OOM | small
Many of these thunderbird users have daily/continuous crashes.

Comment 9

[Intermittent Failures Robot]

1 failures in 3031 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 1

Platform breakdown:

• osx-10-10: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1326539&startday=2019-04-22&endday=2019-04-28&tree=all

Comment 10

[Pascal Chevrel:pascalc (PTO until April 26)]

This crash signature is visible on nightly over the last 2 days at levels similar to what we see on beta usually.

Comment 11

[Marcia Knous [:marcia]]

Looks as if we had a few spikes in 70 nightly between the 22nd and the 24th of July, but since then there has been only one crash. This maps exactly to the bug we fixed that dveditz references, Bug 1567902.

Comment 12

[Wayne Mery (:wsmwk)]

Pablo, all the crashes of the past 3 months are from old versions, so this can be closed IMO

Comment 13

[Pablo]

Thanks, i will close it as WFM
regards.