Closed Bug 1399373 Opened 2 years ago Closed 7 months ago

[W10 Fall Creators Update] Crash in js::jit::BytecodeAnalysis::init while scrolling on Yahoo Music

Categories

(Core :: JavaScript Engine: JIT, defect, P2, critical)

x86
Windows 10
defect

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox-esr60 --- affected
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- unaffected
firefox62 --- affected
firefox63 --- affected

People

(Reporter: ciprian_georgiu, Unassigned)

Details

(Keywords: crash, regression, Whiteboard: [#jsapi:crashes-retriage])

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-ceef90a6-2aa9-45d7-bd86-6d57d0170912.
=============================================================

[Affected versions]:
- Beta 56.0b11
- RC 55.0.3

[Affected platforms]:
- Windows 10 x86  (Version 1703 OS Build 16281.100)

[Steps to reproduce]:
1. Start Firefox.
2. Go to https://www.yahoo.com/music/song-premiere-gracie-abrams-debuts-song-benefit-pediatric-cancer-163907519.html
3. While the page is loading start scrolling up and down with you mouse wheel for about 15 seconds.
- I noticed that sometimes after this step you need to wait for a few seconds to reproduce the crash (see the sceencast: https://drive.google.com/file/d/0B6qEQD4BO4AlNmk3NzNpNW1kSkk/view)

[Expected result]:
- Firefox crashes after the page is scrolled for a few seconds.

[Actual result]:
- No crash while scrolling on page.

[Regression range]:
- This issue seems to be fixed in the latest builds as I cannot reproduce it on Nightly 57.0a1 (2017-09-13).

[Additional notes]:
- on the current Windows 10 release version 1703 (OS Build 15063.540) this crash is not reproducible, only on the latest Insider Preview builds (Version 1703 OS Build 16281.1000)
- please note that I encounter this crash on 32 bit and it's quite intermittent, I was able to repro this in ~3 cases out of 10.
Has Regression Range: --- → no
Has STR: --- → yes
Component: Audio/Video → JavaScript Engine: JIT
Looking at the crash site, it seems most likely that BytecodeAnalysis::init is being called on a script with script->length(), and the |infos_[0].init(/*stackDepth=*/0)| line is thus out of bounds.

I'm not sure if an empty script is legal, but the immediate issue can be addressed by returning true if the length is equal. Otherwise the infos_ vector is somehow null.

This signature seems to show 50 crashes a day on release. https://crash-stats.mozilla.com/signature/?product=Firefox&signature=js%3A%3Ajit%3A%3ABytecodeAnalysis%3A%3Ainit&date=%3E%3D2017-06-18T02%3A10%3A52.000Z&date=%3C2017-09-18T02%3A10%3A52.000Z#graphs
Priority: -- → P2
This is a diagnostic patch to deploy to nightly to move the crash closer to the root cause. Hopefully this will give a quick answer.

(Still running some local testing to make sure this doesn't start failing immediately)
Attachment #8909434 - Flags: review?(nicolas.b.pierron)
Attachment #8909434 - Flags: review?(nicolas.b.pierron) → review+
Assignee: nobody → tcampbell
Status: NEW → ASSIGNED
Marking leave-open as this only helps narrow down bug rather than fixing it.
Keywords: leave-open
Assignee: tcampbell → nobody
Status: ASSIGNED → NEW
Whiteboard: [#jsapi:crashes-retriage]
97 crashes (for the last 6 months) have "MOZ_RELEASE_ASSERT(codeLength > 0)" as moz_crash_reason:
 - https://bit.ly/2yLP9B4

:tcampbell, could you investigate please ?
Flags: needinfo?(tcampbell)
Crash Signature: [@ js::jit::BytecodeAnalysis::init] → [@ js::jit::BytecodeAnalysis::init] [@ JSScript::createScriptData] [@ js::SharedScriptData::new_]
Was 57 actually unaffected?

At this point, these crashes seem related to cache corruption issues in the general vicinity of Bug 1423616. The cases where this release assert is failing indicate corrupted disk caches. Closing this since I've never been able to reproduce the original steps.

Status: NEW → RESOLVED
Closed: 7 months ago
Flags: needinfo?(tcampbell)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.