1573289 - Assertion failure: !hasBlackEntries(), at js/src/gc/Marking.cpp:2485

Status: RESOLVED DUPLICATE of bug 1580888

(Core :: JavaScript Engine, defect, P1)

Description

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

The following testcase crashes on mozilla-central revision 028f522d1e6a (build with --enable-debug --enable-more-deterministic, run with --fuzzing-safe --no-threads --no-baseline --no-ion):

// Adapted from randomly chosen test: js/src/jit-test/tests/gc/weak-marking-varying.js
for (let x of [, 0]) {
    let g = newGlobal();
    g.eval(`enqueueMark("set-color-gray")`);
    g.eval('enqueueMark("unset-color")');
    g.eval('enqueueMark("yield")');
    gcslice(9999);
}

Backtrace:

#0  js::GCMarker::setMarkColorGray (this=0x7fde01f276f8) at js/src/gc/Marking.cpp:2485
#1  0x00005558e5469f21 in js::GCMarker::setMarkColor (this=<optimized out>, newColor=js::gc::MarkColor::Gray) at js/src/gc/Marking.cpp:2480
#2  js::GCMarker::processMarkQueue (this=0x7fde01f276f8) at js/src/gc/Marking.cpp:1593
#3  0x00005558e546b99e in js::gc::GCRuntime::markUntilBudgetExhausted (this=<optimized out>, sliceBudget=..., phase=js::gcstats::PhaseKind::SWEEP_MARK) at js/src/gc/GC.cpp:6072
#4  js::gc::GCRuntime::performSweepActions (this=0x7fde01f266d8, budget=...) at js/src/gc/GC.cpp:6696
#5  0x00005558e547057e in js::gc::GCRuntime::incrementalSlice (this=0x7fde01f266d8, budget=..., gckind=..., reason=JS::GCReason::DEBUG_GC, session=...) at js/src/gc/GC.cpp:7230
/snip

For detailed crash information, see attachment.

Comment 1

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

Attachment: Detailed Crash Information

Comment 2

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

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/4ad75b878827
user: Steve Fink
date: Wed Jul 24 14:29:22 2019 -0700
summary: Backed out changeset 617df479fac1 (bug 1167452)

Another related one? See bug 1570465 comment 3.

Comment 3

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

Without source dir (objdir) specified on Pernosco command prompt:

https://pernos.co/debug/AbriKe9HMKH8m1bhHFYR6w/index.html

With source dir (objdir) specified on Pernosco command prompt:

https://pernos.co/debug/pkn2V4YMEwCzTPBG9aVDEg/index.html

Tested on m-c rev ce8742e6c77b and rr rev cbe18bc1807c9bcc822ba7119d112c3aec2ec0fc and pernosco-submit rev ec0fe133fa05cc438a24e5836482d344079cc595

Comment 4

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

Another pernosco trace with optimization disabled: (edited)

$ PERNOSCO_TEST= ./pernosco-submit upload ~/.local/share/rr/js-dbg-optDisabled-64-linux-x86_64-ce8742e6c77b-0 ~/shell-cache/js-dbg-optDisabled-64-linux-x86_64-ce8742e6c77b/objdir-js/
Running 'rr pack'...
rr: Packed trace directory `/home/ubuntu/.local/share/rr/js-dbg-optDisabled-64-linux-x86_64-ce8742e6c77b-0'.
Copying /usr/lib/x86_64-linux-gnu/libthread_db.so into trace...
Obtaining source file list...
Git repo at /home/ubuntu/rr: Checking for source files changed since revision cbe18bc1807c9bcc822ba7119d112c3aec2ec0fc in remote origin (access via https://raw.githubusercontent.com/mozilla/rr/cbe18bc1807c9bcc822ba7119d112c3aec2ec0fc/)... no changes
Mercurial repo at /home/ubuntu/trees/mozilla-central: Checking for source files changed since revision ce8742e6c77b7aef8a2beba32776ca3494adacb8 in remote 'default' (access via https://hg.mozilla.org/mozilla-central/raw-file/ce8742e6c77b7aef8a2beba32776ca3494adacb8/)... no changes
Packaging 0 modified and 219 non-repository files...
Not uploading source file /usr/include/asm-generic/int-ll64.h (add an allowed source directory to the command line?)
Not uploading source file /usr/include/c++/7/atomic (add an allowed source directory to the command line?)
Not uploading source file /usr/include/c++/7/bits/algorithmfwd.h (add an allowed source directory to the command line?)
Not uploading source file /usr/include/c++/7/bits/alloc_traits.h (add an allowed source directory to the command line?)
Not uploading source file /usr/include/c++/7/bits/allocated_ptr.h (add an allowed source directory to the command line?)
Not uploading source file /usr/include/c++/7/bits/allocator.h (add an allowed source directory to the command line?)
Not uploading source file /usr/include/c++/7/bits/atomic_base.h (add an allowed source directory to the command line?)
Not uploading source file /usr/include/c++/7/bits/char_traits.h (add an allowed source directory to the command line?)
Not uploading source file /usr/include/c++/7/bits/cpp_type_traits.h (add an allowed source directory to the command line?)
Not uploading source file /usr/include/c++/7/bits/exception_ptr.h (add an allowed source directory to the command line?)
(too many disallowed-source-file warnings, suppressing the rest)
Copying file /home/ubuntu/trees/mozilla-central/.gdbinit into trace
Copying file /home/ubuntu/trees/mozilla-central/.gdbinit_python into trace
Compressing to /tmp/tmpq9tuh_hs...
Uploading 79968045 bytes to s3://pernosco-upload/G9nuQ1MhDn8.tar.zst...
upload: ../../../tmp/tmpq9tuh_hs to s3://pernosco-upload/G9nuQ1MhDn8.tar.zst

https://pernos.co/debug/7COvDpxgBEFGvMdAGaAKfA/index.html

AR=ar sh ./configure --enable-debug --disable-optimize --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

Tested on m-c rev ce8742e6c77b and rr rev cbe18bc1807c9bcc822ba7119d112c3aec2ec0fc and pernosco-submit rev ec0fe133fa05cc438a24e5836482d344079cc595

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

We've caught something similar on our CI reproducer. https://pernos.co/debug/zpyMZVQuerISpDIMyYpisg/index.html

Comment 6

[(Away)]

I took a look at this in an attempt to familiarize myself with Pernosco. (Specifically I looked at comment 5, if it matters)

If I understand correctly, we're working on the gray entries:

      do {
        MOZ_ASSERT(!hasBlackEntries());
        processMarkStackTop(budget);
        if (budget.isOverBudget()) {
          return false;
        }
      } while (hasGrayEntries());

We know from the assert that there are no black entries at the start of each iteration. At one point we go over budget and take the early return, the inner AutoSetMarkColor sets us back to black, then the outer AutoSetMarkColor sets us back to gray, and complains.

Does that mean we conclude that processMarkStackTop caused there to be black entries after all? Or possibly the saveValueRanges()?

I guess I should watch the stack positions, though I'm still trying to get comfortable with the interface...

Comment 7

[(Away)]

Ah, it looks like comment 5 / comment 6 are actually a slightly different stack from the one originally filed here. It might still be the same root cause, but if what I'm talking about doesn't make sense when you're looking at one of the other pernosco links, that's why.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Can you help find an owner for this issue? Thanks.

Comment 9

[Steve Fink [:sfink] [:s:]]

I'm attempting to re-land the code that would allow removing this assertion.

Comment 10

[Steven DeTar [:sdetar]]

I believe sfink responded, so clearing needinfo for me

Comment 11

[Steve Fink [:sfink] [:s:]]

Reland attempt is happening in bug 1580888.

Comment 12

[Steve Fink [:sfink] [:s:]]

The patch in bug 1580888 fixes this (test-only) bug. Partly by removing the assertion (since the behavior it's complaining about is now allowed.)