1143960 - Crash [@ js::gc::MovingTracer::Visit]

Status: RESOLVED DUPLICATE of bug 1143706

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 436686833af0 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-debug, run with --fuzzing-safe --thread-count=2 --ion-eager --baseline-eager):

gczeal(14);
while (true)
     foo("");
function foo(f) {
     f.substr(-3) 
     newGlobal();
     x = parseInt(f);
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7f5d700 (LWP 34566)]
0x000000000085584c in js::gc::MovingTracer::Visit (jstrc=0x7ffff7f5cde0, thingp=0x7ffff7f5cd40, kind=<optimized out>) at js/src/jsgc.cpp:2258
#0  0x000000000085584c in js::gc::MovingTracer::Visit (jstrc=0x7ffff7f5cde0, thingp=0x7ffff7f5cd40, kind=<optimized out>) at js/src/jsgc.cpp:2258
#1  0x00000000004e1388 in MarkInternal<JSObject> (trc=trc@entry=0x7ffff7f5cde0, thingp=thingp@entry=0x7ffff7f5cd40) at js/src/gc/Marking.cpp:295
#2  0x0000000000519b99 in js::gc::MarkUnbarriered<JSObject> (trc=trc@entry=0x7ffff7f5cde0, thingp=thingp@entry=0x7ffff7f5cd40, name=name@entry=0xafe038 "global") at js/src/gc/Marking.cpp:315
#3  0x00000000004f8a4b in MarkObjectUnbarriered (name=0xafe038 "global", thingp=0x7ffff7f5cd40, trc=0x7ffff7f5cde0) at js/src/gc/Marking.cpp:610
#4  markChildren (trc=0x7ffff7f5cde0, this=0x7ffff548d040) at js/src/gc/Marking.cpp:1072
#5  js::TraceChildren (trc=trc@entry=0x7ffff7f5cde0, thing=0x7ffff548d040, kind=kind@entry=JSTRACE_BASE_SHAPE) at js/src/gc/Marking.cpp:1837
#6  0x00000000008bb2f3 in UpdateCellPointersTyped<js::BaseShape> (traceKind=JSTRACE_BASE_SHAPE, arena=0x7ffff548d000, trc=0x7ffff7f5cde0) at js/src/jsgc.cpp:2315
#7  UpdateCellPointers (arena=0x7ffff548d000, trc=0x7ffff7f5cde0) at js/src/jsgc.cpp:2356
#8  js::gc::UpdateCellPointersTask::updateArenas (this=this@entry=0x7fffffffc680) at js/src/jsgc.cpp:2523
#9  0x00000000008bb860 in js::gc::UpdateCellPointersTask::run (this=0x7fffffffc680) at js/src/jsgc.cpp:2532
#10 0x00000000005295bf in runFromHelperThread (this=0x7fffffffc680) at js/src/vm/HelperThreads.cpp:817
#11 js::HelperThread::handleGCParallelWorkload (this=this@entry=0x171adc0) at js/src/vm/HelperThreads.cpp:841
#12 0x0000000000535a9e in js::HelperThread::threadLoop (this=0x171adc0) at js/src/vm/HelperThreads.cpp:1405
#13 0x0000000000582af9 in nspr::Thread::ThreadRoutine (arg=0x1719800) at js/src/vm/PosixNSPR.cpp:45
#14 0x00007ffff7bc4182 in start_thread (arg=0x7ffff7f5d700) at pthread_create.c:312
#15 0x00007ffff6cb3fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
rax	0x0	0
rbx	0x7ffff7f5cde0	140737353469408
rcx	0x7ffff548e000	140737308581888
rdx	0xbad0bad1	3134241489
rsi	0x7ffff7f5cd40	140737353469248
rdi	0x7ffff7f5cde0	140737353469408
rbp	0x0	0
rsp	0x7ffff7f5cd08	140737353469192
r8	0x2	2
r9	0x180a790	25208720
r10	0x180a750	25208656
r11	0x7ffff5459ad8	140737308367576
r12	0x7ffff548d000	140737308577792
r13	0xb3bbec	11779052
r14	0xb3c120	11780384
r15	0x1fffffffffffff	9007199254740991
rip	0x85584c <js::gc::MovingTracer::Visit(JSTracer*, void**, JSGCTraceKind)+12>
=> 0x85584c <js::gc::MovingTracer::Visit(JSTracer*, void**, JSGCTraceKind)+12>:	cmp    %rdx,0x8(%rax)
   0x855850 <js::gc::MovingTracer::Visit(JSTracer*, void**, JSGCTraceKind)+16>:	je     0x855858 <js::gc::MovingTracer::Visit(JSTracer*, void**, JSGCTraceKind)+24>


Marking s-s due to GC crash and fuzzblocker because this is a frequent (and highly disruptive/unstable) issue.

Comment 1

[Terrence Cole [:terrence]]

This appears to be fallout from bz's removal of parents -- the global is now marked instead of the parent link, but we're crashing when we mark this new edge during compacting. From the crash the global pointer appears to be null; it is asserted just above, but this is a --disable-debug build.

Comment 2

[Christian Holler (:decoder)]

I just found the mentioned assertion in the fuzzing results as well, with a very easy test. I filed bug 1143963 for that assertion which is most likely the same bug then.

Comment 3

[Terrence Cole [:terrence]]

We compact after sweeping, so I'd expect that if the compartment's global link is swept we'd have fully swept all of the arenas to. JSCompartment::fixupGlobal, however, does a null check here. Jon, do you remember why we needed this? I'm guessing we do, in which case we certainly need one in the marker that runs during relocation too.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Isn't this a duplicate of bug 1143706?

Comment 5

[Jon Coppeard (:jonco)]

(In reply to Terrence Cole [:terrence] from comment #3)
As per bug 1143706 comment 8, the problem is a GC before we've finished creating the global for the compartment in which case it can be null.