Closed Bug 1590904 Opened 5 years ago Closed 5 years ago

Assertion failure: gc->currentSweepGroup, at js/src/gc/GC.cpp:5990

Categories

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

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox-esr68 --- unaffected
firefox67 --- unaffected
firefox68 --- unaffected
firefox69 --- unaffected
firefox70 --- unaffected
firefox71 --- unaffected
firefox72 --- fixed

People

(Reporter: decoder, Assigned: jonco)

References

(Regression)

Details

(4 keywords, Whiteboard: [jsbugmon:update,bisect][fuzzblocker])

Attachments

(1 file)

The following testcase crashes on mozilla-central revision ad7a152bc66c (build with --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --ion-offthread-compile=off):

gczeal(20);
startgc(1);
gczeal(10);
while (gcstate() == "Sweep") {}

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  js::gc::SweepGroupsIter::SweepGroupsIter (rt=<optimized out>, this=0x7ffff5f25210) at js/src/gc/GC.cpp:5990
#1  mozilla::Maybe<js::gc::SweepGroupsIter>::emplace<JSRuntime*&> (this=0x7ffff5f25210) at dist/include/mozilla/Maybe.h:526
#2  IncrementalIter<js::gc::SweepGroupsIter>::IncrementalIter<JSRuntime*&> (maybeIter=..., this=<synthetic pointer>) at js/src/gc/GC.cpp:5966
#3  sweepaction::SweepActionForEach<js::gc::SweepGroupsIter, JSRuntime*>::run (this=0x7ffff5f251f0, args=...) at js/src/gc/GC.cpp:6118
#4  0x0000555556141fd7 in js::gc::GCRuntime::performSweepActions (this=this@entry=0x7ffff5f29710, budget=...) at js/src/gc/GC.cpp:6252
#5  0x0000555556176b90 in js::gc::GCRuntime::incrementalSlice (this=this@entry=0x7ffff5f29710, budget=..., gckind=..., reason=reason@entry=JS::GCReason::DEBUG_GC, session=...) at js/src/gc/GC.cpp:6777
#6  0x0000555556177637 in js::gc::GCRuntime::gcCycle (this=this@entry=0x7ffff5f29710, nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., gckind=..., reason=reason@entry=JS::GCReason::DEBUG_GC) at js/src/gc/GC.cpp:7184
#7  0x0000555556177c3e in js::gc::GCRuntime::collect (this=this@entry=0x7ffff5f29710, nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., gckindArg=..., reason=reason@entry=JS::GCReason::DEBUG_GC) at js/src/gc/GC.cpp:7369
#8  0x0000555556179e60 in js::gc::GCRuntime::runDebugGC (this=this@entry=0x7ffff5f29710) at js/src/gc/GC.cpp:7940
#9  0x000055555617a0a2 in js::gc::GCRuntime::gcIfNeededAtAllocation (this=this@entry=0x7ffff5f29710, cx=cx@entry=0x7ffff5f27000) at js/src/gc/Allocator.cpp:361
#10 0x00005555561b58b8 in js::gc::GCRuntime::checkAllocatorState<(js::AllowGC)1> (this=this@entry=0x7ffff5f29710, cx=cx@entry=0x7ffff5f27000, kind=kind@entry=js::gc::AllocKind::STRING) at js/src/gc/Allocator.cpp:325
#11 0x00005555561b5e9d in js::AllocateStringImpl<JSString, (js::AllowGC)1> (cx=cx@entry=0x7ffff5f27000, heap=heap@entry=js::gc::DefaultHeap) at js/src/gc/Allocator.cpp:203
#12 0x0000555555d7df7b in js::AllocateString<JSThinInlineString, (js::AllowGC)1> (heap=js::gc::DefaultHeap, cx=0x7ffff5f27000) at js/src/gc/Allocator.h:47
#13 JSThinInlineString::new_<(js::AllowGC)1> (cx=0x7ffff5f27000) at js/src/vm/StringType-inl.h:328
#14 js::AllocateInlineString<(js::AllowGC)1, unsigned char> (cx=0x7ffff5f27000, len=5, chars=0x7fffffffc1d8) at js/src/vm/StringType-inl.h:35
#15 0x0000555555db1ce9 in js::NewInlineString<(js::AllowGC)1, unsigned char> (cx=0x7ffff5f27000, chars=...) at js/src/vm/StringType-inl.h:62
#16 js::NewStringCopyNDontDeflate<(js::AllowGC)1, unsigned char> (cx=0x7ffff5f27000, s=<optimized out>, n=5) at js/src/vm/StringType.cpp:1892
#17 0x0000555555bf2b34 in ReturnStringCopy (cx=<optimized out>, args=..., message=<optimized out>) at js/src/builtin/TestingFunctions.cpp:440
#18 0x0000555555bfbe58 in GCState (cx=<optimized out>, argc=<optimized out>, vp=<optimized out>) at js/src/builtin/TestingFunctions.cpp:1412
#19 0x000011a325f4935b in ?? ()
#20 0x0000555557fd5aa0 in js::jit::vmFunctions ()
#21 0x00007fffffffc2f8 in ?? ()
#22 0x0000000000003820 in ?? ()
#23 0x0000000000000000 in ?? ()
rax	0x555558071fa0	93825037442976
rbx	0x7ffff5f251f0	140737319686640
rcx	0x555556f1d688	93825019270792
rdx	0x0	0
rsi	0x7ffff6eeb770	140737336227696
rdi	0x7ffff6eea540	140737336223040
rbp	0x7fffffffbb20	140737488337696
rsp	0x7fffffffba60	140737488337504
r8	0x7ffff6eeb770	140737336227696
r9	0x7ffff7fe6cc0	140737354034368
r10	0x58	88
r11	0x7ffff6b927a0	140737332717472
r12	0x7fffffffbb50	140737488337744
r13	0x7fffffffba70	140737488337520
r14	0x7ffff5f25210	140737319686672
r15	0x7fffffffbb50	140737488337744
rip	0x5555561b4729 <sweepaction::SweepActionForEach<js::gc::SweepGroupsIter, JSRuntime*>::run(js::gc::SweepAction::Args&)+1113>
=> 0x5555561b4729 <sweepaction::SweepActionForEach<js::gc::SweepGroupsIter, JSRuntime*>::run(js::gc::SweepAction::Args&)+1113>:	movl   $0x0,0x0
   0x5555561b4734 <sweepaction::SweepActionForEach<js::gc::SweepGroupsIter, JSRuntime*>::run(js::gc::SweepAction::Args&)+1124>:	ud2

Unlikely to be s-s, looks like a problem in the gcstate helper function. However, this is ocurring at high frequency, so marking as fuzzblocker.

Assignee: nobody → jcoppeard
Priority: -- → P1

The problem here was that we were returning NotFinished from GCRuntime::performSweepActions when the sweep group iterator indicated that we had finished sweeping all groups. This was because the background marking task had not finished and was causing us to return NotFinished. This shouldn't be possible because when we start sweeping the last sweep group there are no more groups left to mark and we wait for the marking task to finish in GCRuntime::endMarkingSweepGroup.

The problem was that we were starting the mark task even when there was no marking to do and it checks the budget before performing any work. The fix is to not start the task if there's no work to do (if the mark stack is already drained).

Pushed by jcoppeard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7542922a6323 Don't start background marking task if there's nothing to mark r=allstarschh
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72

Crash found with fuzzing, it seems to me that this can ride the trains. Marking as wontfix for 71. If there is a case for uplifting this bug to beta, please contact me, thanks.

Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: