Closed
Bug 1384047
Opened 7 years ago
Closed 7 years ago
Assertion failure: compartments_.ref().empty(), at js/src/gc/Zone.cpp:76
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | unaffected |
firefox56 | --- | fixed |
People
(Reporter: gkw, Assigned: jonco)
References
Details
(Keywords: assertion, bugmon, testcase, Whiteboard: [jsbugmon:update])
Attachments
(2 files)
7.94 KB,
text/plain
|
Details | |
1.78 KB,
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision 131e19a573e9 (build with --enable-debug --enable-more-deterministic --without-intl-api, run with --fuzzing-safe --no-threads --no-baseline --no-ion): // jsfunfuzz-generated newGlobal(); // Adapted from randomly chosen test: js/src/jit-test/tests/gc/oomInNewGlobal.js evalcx("oomTest(newGlobal);", newGlobal()); newGlobal(); Backtrace: #0 0x0000000000e61db8 in JS::Zone::~Zone (this=0x7ff3427c2000, __in_chrg=<optimized out>) at js/src/gc/Zone.cpp:76 #1 0x00000000009b7cac in js_delete<JS::Zone> (p=0x7ff3427c2000) at /home/gkwubu/shell-cache/js-dbg-64-dm-intlDisabled-linux-131e19a573e9/objdir-js/dist/include/js/Utility.h:384 #2 js::ScopedDeletePtrTraits<JS::Zone>::release (ptr=0x7ff3427c2000) at /home/gkwubu/shell-cache/js-dbg-64-dm-intlDisabled-linux-131e19a573e9/objdir-js/dist/include/js/Utility.h:459 #3 mozilla::Scoped<js::ScopedDeletePtrTraits<JS::Zone> >::~Scoped (this=0x7ffcd14c1ec0, __in_chrg=<optimized out>) at /home/gkwubu/shell-cache/js-dbg-64-dm-intlDisabled-linux-131e19a573e9/objdir-js/dist/include/mozilla/Scoped.h:95 #4 js::ScopedJSDeletePtr<JS::Zone>::~ScopedJSDeletePtr (this=0x7ffcd14c1ec0, __in_chrg=<optimized out>) at /home/gkwubu/shell-cache/js-dbg-64-dm-intlDisabled-linux-131e19a573e9/objdir-js/dist/include/js/Utility.h:461 #5 js::NewCompartment (cx=cx@entry=0x7ff342772000, principals=principals@entry=0x0, options=...) at js/src/jsgc.cpp:7294 #6 0x0000000000b6d486 in js::GlobalObject::new_ (cx=cx@entry=0x7ff342772000, clasp=clasp@entry=0x133ee00 <global_class>, principals=principals@entry=0x0, hookOption=hookOption@entry=JS::DontFireOnNewGlobalHook, options=...) at js/src/vm/GlobalObject.cpp:349 /snip For detailed crash information, see attachment. This seems fairly innocuous as it involves oomTest, but since GC is in the assertion message file list and a bunch of gc zone stuff on the stack, setting s-s to be safe.
Reporter | ||
Comment 2•7 years ago
|
||
Reporter | ||
Comment 3•7 years ago
|
||
autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/451efff6cf90 user: Jon Coppeard date: Mon Jul 24 10:42:50 2017 +0100 summary: Bug 1366340 - Delete parsing zones immediately after their contents are merged r=sfink Jon, is bug 1366340 a likely regressor?
Blocks: 1366340
Flags: needinfo?(jcoppeard)
Assignee | ||
Comment 4•7 years ago
|
||
Yes, the assertion I added doesn't always hold. It's not a security issue though.
Assignee: nobody → jcoppeard
Group: javascript-core-security
Flags: needinfo?(jcoppeard)
Assignee | ||
Comment 5•7 years ago
|
||
I previously added an assertion to ~Zone() that the zone had no compartments, but this doesn't hold when we delete a zone if we fail in NewCompartment(). This patch moves the assertion to Zone::destroy() which is the path used by the GC to delete a zone.
Attachment #8890272 -
Flags: review?(jdemooij)
Updated•7 years ago
|
Attachment #8890272 -
Flags: review?(jdemooij) → review+
Pushed by jcoppeard@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/5f396e8e22fa Relax assertion that zones are empty when they are deleted r=jandem
Comment 7•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/5f396e8e22fa
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Updated•7 years ago
|
status-firefox54:
--- → unaffected
status-firefox55:
--- → unaffected
status-firefox-esr52:
--- → unaffected
You need to log in
before you can comment on or make changes to this bug.
Description
•