1124653 - Crash [@ simulatorRuntime] or [@ js::jit::Simulator::FlushICache]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 34e2d2bd7ec4 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --enable-arm-simulator --disable-debug, run with --fuzzing-safe --thread-count=2 --ion-eager --arm-sim-icache-checks --ion-offthread-compile=off):

var o = {};
gczeal(14);
for (var i = 0; i < 200; i++) {
    with (o) { }
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf7aa9b40 (LWP 15802)]
0x08353c59 in simulatorRuntime (this=0x0) at js/src/jit/arm/Simulator-arm.cpp:4447
4447	    return simulatorRuntime_;
#0  0x08353c59 in simulatorRuntime (this=0x0) at js/src/jit/arm/Simulator-arm.cpp:4447
#1  simulatorRuntime (this=<optimized out>) at js/src/jit/arm/Simulator-arm.cpp:4435
#2  js::jit::Simulator::FlushICache (start_addr=0xf7820034, size=4) at js/src/jit/arm/Simulator-arm.cpp:1103
#3  0x08330da9 in TraceOneDataRelocation<js::jit::InstructionIterator> (masm=0x0, iter=0xf7aa9110, trc=0xf7aa9244) at js/src/jit/arm/Assembler-arm.cpp:815
#4  TraceDataRelocations (masm=0x0, reader=..., buffer=0xf781fe48 "\004\340-\345\005", trc=0xf7aa9244) at js/src/jit/arm/Assembler-arm.cpp:828
#5  js::jit::Assembler::TraceDataRelocations (trc=0xf7aa9244, code=0xf5d55178, reader=...) at js/src/jit/arm/Assembler-arm.cpp:846
#6  0x081c4d95 in js::jit::JitCode::trace (this=0xf5d55178, trc=0xf7aa9244) at js/src/jit/Ion.cpp:652
#7  0x08121874 in MarkChildren (code=0xf5d55178, trc=0xf7aa9244) at js/src/gc/Marking.cpp:1479
#8  js::TraceChildren (trc=0xf7aa9244, thing=0xf5d55178, kind=JSTRACE_JITCODE) at js/src/gc/Marking.cpp:1921
#9  0x08368480 in UpdateCellPointersTyped<js::jit::JitCode> (trc=0xf7aa9244, arena=0xf5d55000, traceKind=traceKind@entry=JSTRACE_JITCODE) at js/src/jsgc.cpp:2307
#10 0x083b5e70 in UpdateCellPointers (trc=trc@entry=0xf7aa9244, arena=arena@entry=0xf5d55000) at js/src/jsgc.cpp:2354
#11 0x083bc761 in updateArenas (this=0xffffcbb0) at js/src/jsgc.cpp:2513
#12 js::gc::UpdateCellPointersTask::run (this=0xffffcbb0) at js/src/jsgc.cpp:2522
#13 0x08496857 in js::GCParallelTask::runFromHelperThread (this=0xffffcbb0) at js/src/vm/HelperThreads.cpp:810
#14 0x084a1c93 in handleGCParallelWorkload (this=0x92d46e8) at js/src/vm/HelperThreads.cpp:834
#15 js::HelperThread::threadLoop (this=0x92d46e8) at js/src/vm/HelperThreads.cpp:1388
#16 0x08493dc5 in nspr::Thread::ThreadRoutine (arg=0x92d3480) at js/src/vm/PosixNSPR.cpp:45
#17 0xf7fb5d4c in start_thread (arg=0xf7aa9b40) at pthread_create.c:308
#18 0xf7da5d3e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
eax	0x0	0
ebx	0x92b6ff4	153841652
ecx	0xf7aa9bcc	-139813940
edx	0x0	0
esi	0xf7820034	-142475212
edi	0x4	4
ebp	0xf5d44040	4124328000
esp	0xf7aa90b0	4155150512
eip	0x8353c59 <js::jit::Simulator::FlushICache(void*, unsigned int)+89>
=> 0x8353c59 <js::jit::Simulator::FlushICache(void*, unsigned int)+89>:	mov    0x8760(%eax),%ebp
   0x8353c5f <js::jit::Simulator::FlushICache(void*, unsigned int)+95>:	mov    0x14(%ebp),%eax


Marking s-s because it's a GC crash. Although the crash happens in simulator code, it might indicate a non-simulator problem, esp. since the icache checks need to be enabled for the bug to trigger.

Comment 1

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/26d8f946a53b
user:        Jon Coppeard
date:        Fri Jan 16 14:34:32 2015 +0000
summary:     Bug 650161 - Enable compacting GC on GC_SHRINK collections r=terrence r=glandium

This iteration took 499.610 seconds to run.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

This is happening very often for jsfunfuzz, setting [fuzzblocker], especially with js::jit::Simulator::FlushICache on the stack.

Jon, is compacting GC a likely regressor?

Comment 3

[Jon Coppeard (:jonco)]

Oh, the simulator doesn't like being called off main thread.  Yes this is caused by compacting.  I think we need to make sure JitCode cells are updated on the main thread, certainly if we are using the simulator and maybe in all cases.

Comment 4

[Jon Coppeard (:jonco)]

Attachment: bug1124653-simulator-crash

In general, let's only update cells on a background thread if they support background finalization.  This gives us the same behvaiour as before except JitCode is now updated in the foreground.

Also, update foreground things on the main thread rather than just on a single helper thread, so that the simulator can find its TLS.

Comment 5

[Terrence Cole [:terrence]]

Comment on attachment 8556522 [details] [diff] [review]
bug1124653-simulator-crash

Review of attachment 8556522 [details] [diff] [review]:
-----------------------------------------------------------------

I figured we'd have to get back here eventually -- there was no way parallelizing marking was going to be that easy. ;-)

::: js/src/jsgc.cpp
@@ +2504,5 @@
> +    {
> +        AutoLockHelperThreadState lock;
> +        unsigned i;
> +        for (i = 0; i < taskCount && !bgArenas.done(); ++i) {
> +            ArenasToUpdate *source = i == 0 ? &fgArenas : &bgArenas;

Source for i==0 is still fgArenas here, so it seems like fgTask and bgTask[0] are pointing at the same list?

Comment 6

[Jon Coppeard (:jonco)]

Attachment: bug1124653-simulator-crash v2

Well spotted, I meant to remove that!

Comment 7

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7168b1244974

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/7168b1244974

Comment 9

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.