Closed
Bug 1497107
Opened 6 years ago
Closed 6 years ago
Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.), at js/src/ds/LifoAlloc.cpp:145
Categories
(Core :: JavaScript Engine, defect, P2)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla65
People
(Reporter: bc, Assigned: iain)
References
()
Details
(Keywords: assertion, reproducible)
Attachments
(2 files)
https://creatoracademy.youtube.com/page/course-exam/get-discovered?hl=en or https://variety.com/2018/film/reviews/putins-witnesses-review-1202866751/ Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.), at z:/build/build/src/js/src/ds/LifoAlloc.cpp:145 Bughunter found on Windows, I reproduced locally on Linux (may require reload). No crash on opt at least locally on Linux.
Comment 1•6 years ago
|
||
This is a debug-only assertion, which checks that we have a fallible allocator when we allocate new chunks. In release build this should crash only on actual OOM. This bug should be actionable from the stack trace.
Comment 2•6 years ago
|
||
Iain, do you mind continuing on fixing these IonBuilder missing checks for ensureBalast?
Assignee | ||
Comment 3•6 years ago
|
||
This bug looks much more tractable than my last ensureBallast bug. The problem is IonBuilder::freezePropertiesForCommonPrototype: https://searchfox.org/mozilla-central/source/js/src/jit/IonBuilder.cpp#10401-10430 There are two nested loops. The outer loop iterates over the contents of a TemporaryTypeSet (in this case, with capacity 64). The inner loop walks up the prototype chain, calling isOwnProperty on each element. isOwnProperty allocates ~64 bytes each time it is called, and we call it nearly 400 times before running out of ballast (even though we had more than enough ballast when entering this function.) The script that triggers the bug is on line 144 of this youtube webcomponents js: https://creatoracademy.youtube.com/frontend_polymer/js_redesign/webcomponentsjs/webcomponents-lite.js. I haven't made an effort at a cutdown testcase yet. Awkwardly, freezePropertiesForCommonPrototype is a couple of levels deep in code that does not expect to be able to fail, so it will take a little bit of surgery to fix this.
Flags: needinfo?(iireland)
Assignee | ||
Comment 4•6 years ago
|
||
Pushed by iireland@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/136188d4f928 Add ensureBallast call to freezePropertiesForCommonPrototype r=nbp
Comment 6•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/136188d4f928
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Updated•6 years ago
|
Assignee: nobody → iireland
Updated•6 years ago
|
status-firefox63:
--- → wontfix
status-firefox64:
--- → wontfix
status-firefox-esr60:
--- → wontfix
Flags: in-testsuite+
Comment hidden (spam) |
Assignee | ||
Updated•4 years ago
|
Flags: needinfo?(iireland)
You need to log in
before you can comment on or make changes to this bug.
Description
•