GenerationalGC: Crash [@ GetGCThingRuntime] with poisoned pointer

RESOLVED FIXED in mozilla30

Status

()

--
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: decoder, Assigned: terrence)

Tracking

(Blocks: 1 bug, {crash, testcase})

Trunk
mozilla30
x86
Linux
crash, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [jsbugmon:ignore], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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();
(Reporter)

Comment 1

5 years ago
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)

Updated

5 years ago
Assignee: nobody → terrence
(Assignee)

Comment 2

5 years ago
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.
(Reporter)

Comment 4

5 years ago
Fwiw I'm still hitting this on GGC fuzzing.
(Assignee)

Comment 5

5 years ago
This is a missing post-barrier in IonBuilder::jsop_rest. Will have a patch momentarily.
Assignee: nobody → terrence
(Assignee)

Comment 6

5 years ago
Created attachment 8378706 [details] [diff] [review]
missing_barrier_jsop_rest-v0.diff

Add a post barrier to the relevant element initializations.
Attachment #8378706 - Flags: review?(shu)
(Assignee)

Comment 7

5 years ago
I was not able to reduce this testcase to something that runs in finite time with the bug fixed.
Flags: in-testsuite-

Comment 8

5 years ago
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+
(Assignee)

Comment 9

5 years ago
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.
https://hg.mozilla.org/mozilla-central/rev/a20e77e55c4f
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.