1645377 - Assertion failure in StoreBuffer::put while fuzzing

Status: RESOLVED FIXED

(Core :: JavaScript: GC, defect, P2)

Description

[Jon Coppeard (:jonco)]

decoder found the following assertion failure while fuzzing. Unreproducible, but the stack trace should be enough to fix this.

Assertion failure: (CurrentThreadCanAccessRuntime(runtime_) && !lock_.isHeld()) || lock_.ownedByCurrentThread(), at /builds/worker/checkouts/gecko/js/src/gc/StoreBuffer.h:393

#0  0x568b4ed3 in void js::gc::StoreBuffer::put<js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::ValueEdge>, js::gc::StoreBuffer::ValueEdge>(js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::ValueEdge>&, js::gc::StoreBuffer::ValueEdge const&) ()
[Current thread is 1 (Thread 0xf6301b40 (LWP 27240))]
#0  0x568b4ed3 in void js::gc::StoreBuffer::put<js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::ValueEdge>, js::gc::StoreBuffer::ValueEdge>(js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::ValueEdge>&, js::gc::StoreBuffer::ValueEdge const&) ()
#1  0x568b4bf7 in js::InternalBarrierMethods<JS::Value>::postBarrier(JS::Value*, JS::Value const&, JS::Value const&) ()
#2  0x56c7e612 in JS::GCVector<JS::Heap<JS::Value>, 0u, js::SystemAllocPolicy>::sweep() ()
#3  0x56c7e35f in JS::WeakCache<JS::GCVector<JS::Heap<JS::Value>, 0u, js::SystemAllocPolicy> >::sweep(js::gc::StoreBuffer*) ()
#4  0x57198556 in ImmediateSweepWeakCacheTask::run() ()
#5  0x57184c18 in js::GCParallelTask::runTask() ()
#6  0x57184991 in js::GCParallelTask::runFromHelperThread(js::AutoLockHelperThreadState&) ()
#7  0x56ac33ef in js::HelperThread::handleGCParallelWorkload(js::AutoLockHelperThreadState&) ()
#8  0x56ac536c in js::HelperThread::threadLoop() ()
#9  0x56ac01f5 in js::HelperThread::ThreadMain(void*) ()
#10 0x56ae3cf3 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) ()
#11 0xf775d26a in start_thread (arg=0xf6301b40) at pthread_create.c:333
#12 0xf73e641e in clone () from /lib32/libc.so.6
eax	0x57eae114	1475010836
ebx	0x59247000	1495560192
ecx	0x59247fd4	1495564244
edx	0x0	0
esi	0x2	2
edi	0xf6534244	-162315708
ebp	0xf6300d98	4130344344
esp	0xf6300d80	4130344320
eip	0x568b4ed3 <void js::gc::StoreBuffer::put<js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::ValueEdge>, js::gc::StoreBuffer::ValueEdge>(js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::ValueEdge>&, js::gc::StoreBuffer::ValueEdge const&)+115>
=> 0x568b4ed3 <_ZN2js2gc11StoreBuffer3putINS1_14MonoTypeBufferINS1_9ValueEdgeEEES4_EEvRT_RKT0_+115>:	movl   $0x189,0x0
   0x568b4edd <_ZN2js2gc11StoreBuffer3putINS1_14MonoTypeBufferINS1_9ValueEdgeEEES4_EEvRT_RKT0_+125>:	call   0x567a2f3b <abort>

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1470369

Comment 2

[Jon Coppeard (:jonco)]

Attachment: Bug 1645377 - Simplify the store buffer access invariant to always require taking the lock from within the GC r?sfink

Previously this requiring no lock for main thread access, but I'd forgotten about the fact that helper thread tasks can get run on the main thread.

This patch simplifies the invariant so that we always require the lock when called from within the GC and fixes the places this didn't happen. This adds some extra locking but this will always be uncontended and shouldn't have a performance impact.

Depends on D79862

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/934e959205ab
Simplify the store buffer access invariant to always require taking the lock from within the GC r=sfink

Comment 4

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/934e959205ab