Closed Bug 961875 Opened 11 years ago Closed 11 years ago

GenerationalGC: Crash [@ GetGCThingRuntime] with poisoned pointer

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: decoder, Assigned: terrence)

References

Details

(Keywords: crash, testcase, Whiteboard: [jsbugmon:ignore])

Crash Data

Attachments

(1 file)

The following testcase crashes on mozilla-central built with --enable-exact-rooting --enable-gcgenerational, revision 4e671e3183c4 (run with --fuzzing-safe): function x() { return ""; } x().split(','); function test() { try { [1].some(function (expect = this, ... m) test()); } catch (ex) {} foo; } test();
Looks unhealthy: Program received signal SIGSEGV, Segmentation fault. GetGCThingRuntime (thing=0x2b2b2b2b) at ../../dist/include/js/HeapAPI.h:133 133 return *reinterpret_cast<JS::shadow::Runtime **>(addr); (gdb) bt 32 #0 GetGCThingRuntime (thing=0x2b2b2b2b) at ../../dist/include/js/HeapAPI.h:133 #1 isTenured (this=0x2b2b2b2b) at js/src/gc/Heap.h:1055 #2 js::gc::Cell::arenaHeader (this=0x2b2b2b2b) at js/src/gc/Heap.h:964 #3 0x080b40d7 in tenuredZone (this=0x2b2b2b2b) at js/src/gc/Heap.h:1024 #4 zone (this=0x2b2b2b2b) at js/src/gc/Barrier.h:185 #5 js::gc::BarrieredCell<js::ObjectImpl>::zone (this=0xf69fffb0) at js/src/vm/ObjectImpl.h:1550 #6 0x08198dd6 in js::GCMarker::processMarkStackTop (this=0x92df2a8, budget=...) at js/src/gc/Marking.cpp:1404 #7 0x08157354 in js::GCMarker::drainMarkStack (this=0x92df2a8, budget=...) at js/src/gc/Marking.cpp:1490 #8 0x0842c115 in DrainMarkStack (phase=js::gcstats::PHASE_MARK, sliceBudget=..., rt=0x92df018) at js/src/jsgc.cpp:4062 #9 IncrementalCollectSlice (rt=0x92df018, budget=154006184, reason=JS::gcreason::TOO_MUCH_MALLOC, gckind=js::GC_NORMAL) at js/src/jsgc.cpp:4622 #10 0x0842e4a0 in GCCycle (rt=0x92df018, incremental=<optimized out>, budget=0, gckind=js::GC_NORMAL, reason=JS::gcreason::TOO_MUCH_MALLOC) at js/src/jsgc.cpp:4786 #11 0x0842ebe7 in Collect (rt=0x92df018, incremental=<optimized out>, budget=0, gckind=js::GC_NORMAL, reason=JS::gcreason::TOO_MUCH_MALLOC) at js/src/jsgc.cpp:4924 #12 0x08430bfb in GCSlice (millis=0, reason=<optimized out>, gckind=js::GC_NORMAL, rt=0x92df018) at js/src/jsgc.cpp:4969 #13 js_InvokeOperationCallback (cx=0x92f61b8) at js/src/jscntxt.cpp:1017 #14 0xf66f64cb in ?? () #15 0xf66dfc73 in ?? ()
Assignee: nobody → terrence
Did not repro on x64 apple. Looks like getting clang to not crash when cross compiling may be non-trivial.
Assignee: terrence → nobody
Reproduces for me on x64 linux, although not on every attempt. Adding --ion-parallel-compile=off makes it repro every time. It concerns infinite recursion, so it might be related to bug 952818.
Fwiw I'm still hitting this on GGC fuzzing.
This is a missing post-barrier in IonBuilder::jsop_rest. Will have a patch momentarily.
Assignee: nobody → terrence
Add a post barrier to the relevant element initializations.
Attachment #8378706 - Flags: review?(shu)
I was not able to reduce this testcase to something that runs in finite time with the bug fixed.
Flags: in-testsuite-
Comment on attachment 8378706 [details] [diff] [review] missing_barrier_jsop_rest-v0.diff Review of attachment 8378706 [details] [diff] [review]: ----------------------------------------------------------------- Good catch, thanks for fixing this. For posterity: should have less ad-hoc ways of adding post barriers so the lesser of us don't forget as much.
Attachment #8378706 - Flags: review?(shu) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/a20e77e55c4f (In reply to Shu-yu Guo [:shu] from comment #8) > For posterity: should have less ad-hoc ways of adding post barriers so the > lesser of us don't forget as much. I strongly agree and will certainly be redesigning the interface at some point.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: