Closed Bug 1612863 Opened 9 months ago Closed 9 months ago

Crash [@ XPCJSContext::Initialize()] due to InitSelfHostedCode failed

Categories

(Core :: JavaScript Engine, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla74
Tracking Status
firefox-esr68 --- unaffected
firefox72 --- wontfix
firefox73 + wontfix
firefox74 + fixed

People

(Reporter: pascalc, Assigned: tcampbell)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #1608690 +++

This crash was initially filed as a non-frequent intermittent failure. The crash history shows that this crash exploded with the release of 72 with about 70 startup crashes per day since we shipped 72.
These startup crashes are still visible in 73 beta and 74 nightly.

The crash reason for these crashes is MOZ_RELEASE_ASSERT(JS::InitSelfHostedCode(cx)) (InitSelfHostedCode failed)

This is a failure somewhere inside the JS engine, so I'm going to move it over there. I remember seeing some previous reports for very early crashes like this, but I don't recall the specifics.

Component: XPConnect → JavaScript Engine
Summary: Intermittent /offscreen-canvas/fill-and-stroke-styles/2d.pattern.repeat.case.html | application crashed [@ XPCJSContext::Initialize()] → Crash [@ XPCJSContext::Initialize()] due to InitSelfHostedCode failed

It looks like about half of these are content process crashes, and the other half are main process crashes at startup.

Bug 1567902 is the past occurrance of this. I'll see what happens if I set the extra warnings flag locally.

See Also: → 1567902

(In reply to Ted Campbell [:tcampbell] from comment #4)

Bug 1567902 is the past occurrance of this. I'll see what happens if I set the extra warnings flag locally.

Note that bug 1568546 enabled extraWarnings unconditionally for self-hosting code so that pref should no longer make a difference.

This started in 72 when Bug 1579367 added the release asserts. Previously the crash was Bug 1567902 which had a mix of bugs and OOM.
I'll add a diagnostic patch to separate the crash reason of OOM from other things.

See Also: → 1579367, 1326539
Assignee: nobody → tcampbell
Status: NEW → ASSIGNED

The browser is unable to start if this operation fails, but we should track
the difference between OOM and other forms of failure. This should now
classify OOM errors correctly in crash stats.

Depends on D61778

Pushed by tcampbell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/379e31437615
Add JS_IsThrowingOutOfMemory API. r=jandem
https://hg.mozilla.org/integration/autoland/rev/301e3381a8e8
Use OOM crash when InitSelfHostedCode fails. r=mccr8
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74

On nightly, the patch seems to have turned the crashes into ooms which is what the theory was.
See signature: [@ OOM | unknown | NS_ABORT_OOM | XPCJSContext::Initialize ]

Once this has made it to Beta for a few days, we can take a look at if non-OOM crashes remain. Otherwise there isn't much to do here.

Crash Signature: [@ XPCJSContext::Initialize] → [@ XPCJSContext::Initialize] [@ enum nsresult XPCJSContext::Initialize + 0x911]
See Also: → 1615310

There are a couple of non-OOM crashes with this signature on beta, but they seem to be bizarre JIT crashes that might just be memory errors.

Crash Signature: [@ XPCJSContext::Initialize] [@ enum nsresult XPCJSContext::Initialize + 0x911] → [@ XPCJSContext::Initialize] [@ enum nsresult XPCJSContext::Initialize + 0x911]
You need to log in before you can comment on or make changes to this bug.