Closed Bug 1567902 Opened 3 years ago Closed 3 years ago

Crash in [@ nsXPConnect::InitStatics]


(Core :: JavaScript Engine, defect)

Windows 7
Not set



Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- unaffected
firefox70 + fixed


(Reporter: marcia, Assigned: anba)




(Keywords: crash, regression)

Crash Data


(1 file)

Seen while looking at nightly crash stats - crashes started in 20190719215614: All crashes have MOZ_CRASH(InitSelfHostedCode failed).

Possible regression range based on Build ID:

This has amassed 312 crashes, but only 31 installations so far. ni on Steven for triage since we are a few days in to the spike, and we should probably figure out what caused it.

Flags: needinfo?(sdetar)

Ted, do you who would be a good person on the JS team to look at this?

Flags: needinfo?(sdetar) → needinfo?(tcampbell)

I have a dead profile because of this bug. Other profiles work fine, my main one won't start any content processes anymore. The browser chrome and at least some chrome-privileged about: pages work (about:crashes, about:addons, about:support), but all I have is the main Firefox process and the Socket process. No child processes. In case it's a clue this seems to have started when my webextension process seemed to be "stuck" (high CPU, pages were frozen) so I killed it. After that browser is non-functional, even after restarting and updating.

A high number of today's crashes are from me. It seems to send off many crash reports every time I restart. More than I have windows (4), but fewer than I have tabs open (150-ish?). There are 10 new crashes each restart (one for each child process that didn't start?), but only 4 get submitted. The others show up in "unsubmitted" and fail when I try to manually submit them. Are these failures logged anywhere, and would that log be useful?

Anything you want me to preserve for investigation? Otherwise I think it's new-profile time.

InitSelfHostedCode only returns false for four reasons:

if (!rt->initializeAtoms(cx)) { ...
if (!rt->createJitRuntime(cx)) { ...
if (!rt->initSelfHosting(cx)) { ...
if (!rt->parentRuntime && !rt->initMainAtomsTables(cx)) { ...

Those all sound pretty generic. Which ones are going to depend on profile data?

Thanks for poking at this. Yeah, I'm a bit confused on which of those is affected by profile data. The rt->initSelfHosting will invoke the spidermonkey js frontend on a piece of JS that is burned into XUL.

The one wild theory that I am wondering about is if the watchdog timeout is corrupted and we are killing initSelfHosting as taking too long to start (based on a broken timeout value). This could also be consistent with webextensions process exploding since it also has a watchdog timer pref, and probably wouldn't like a stream of timeout exceptions being thrown.

There is an older variant with the same crash signature in Bug 1326539 that was never solved.

See Also: → 1326539

Daniel, I had the same crash this morning and was able to narrow it down on my system to having javascript.options.strict set to true in my main profile. After removing that I no longer experienced the crash. Could you check if this is set in your profile and if so, does removing it resolve this for you?

Flags: needinfo?(dveditz)

Good find! If I do a JS shell release build with local changes to set the extraWarnings flag before we call InitSelfHostedCode, I get this:

self-hosted:1700:39 mistyped ; after conditional?:
self-hosted:1700:39     if (!callFunction(ts.nextToken, ts)) ;;;
self-hosted:1700:39 .......................................^

Maybe we should always set extraWarnings when we compile self hosted code...

(In reply to Jan de Mooij [:jandem] from comment #7)

Maybe we should always set extraWarnings when we compile self hosted code...

Oh, DEBUG builds already do that, but not release builds:

Regressed by: 1522070

Wow, that's unexpected. Sorry for the trouble!

Flags: needinfo?(dveditz)
Flags: needinfo?(tcampbell)
Blocks: 1568546

I filed bug 1568546 to prevent similar issues in the future.

Pushed by
Don't emit an if-statement with an elided assertion in self-hosted code. r=jandem

Keywords: checkin-needed
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Assignee: nobody → andrebargull
See Also: → 1612863
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.