754242 - Assertion failure: incBitmap.isMarked(cell, BLACK), at jsgc.cpp:3125 Crash [@ js::HeapPtr<js::BaseShape, unsigned int>::operator] or Crash [@ getCode]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

Attachment: Log for opt-build Valgrind errors

The following test asserts/crashes/shows Valgrind errors on mozilla-central revision 4c6d01c92dcc (options -m -n -a):


var g1 = newGlobal('new-compartment');
schedulegc(g1);
gcslice(0);
function testEq(b) {
    var a = deserialize(serialize(b));
}
testEq(Array(1024).join(Array(1024).join((false))));



After stepping through the assertion I get this crash on the debug build:

Program received signal SIGSEGV, Segmentation fault.
0x0805aad4 in js::HeapPtr<js::BaseShape, unsigned int>::operator js::BaseShape* (this=0xdadadada) at ../../gc/Barrier.h:212
212         operator T*() const { return value; }
(gdb) bt 8
#0  0x0805aad4 in js::HeapPtr<js::BaseShape, unsigned int>::operator js::BaseShape* (this=0xdadadada) at ../../gc/Barrier.h:212
#1  0x0804d24d in js::Shape::base (this=0xdadadada) at ../../jsscope.h:708
#2  0x0804d18f in js::Shape::getObjectClass (this=0xdadadada) at ../../jsscope.h:607
#3  0x0804e269 in js::ObjectImpl::getClass (this=0xf7503040) at ../../vm/ObjectImpl-inl.h:245
#4  0x0804e27d in js::ObjectImpl::hasClass (this=0xf7503040, c=0x85dabe0) at ../../vm/ObjectImpl-inl.h:257
#5  0x0805fdf1 in JSObject::isWith (this=0xf7503040) at ../../jsobjinlines.h:817
#6  0x081472c5 in js::IsActiveWithOrBlock (cx=0x861dd80, obj=..., stackDepth=0) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:947
#7  0x0814b898 in js::Interpret (cx=0x861dd80, entryFrame=0xf7702020, interpMode=js::JSINTERP_NORMAL) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:1890


More interesting however is the behavior on opt-builds. In GDB I get this crash:

Program received signal SIGSEGV, Segmentation fault.
getCode (cx=0x8360a68, script=0xf75060f8, pc=0x836b785 ":", rval=...) at ../jsanalyze.h:958
958         Bytecode& getCode(const jsbytecode *pc) { return getCode(pc - script->code); }
(gdb) bt 8
#0  getCode (cx=0x8360a68, script=0xf75060f8, pc=0x836b785 ":", rval=...) at ../jsanalyze.h:958
#1  bytecodeTypes (cx=0x8360a68, script=0xf75060f8, pc=0x836b785 ":", rval=...) at ../jsanalyze.h:984
#2  js::types::TypeMonitorResult (cx=0x8360a68, script=0xf75060f8, pc=0x836b785 ":", rval=...) at /srv/repos/mozilla-central/js/src/jsinfer.cpp:4966
#3  0x080c65e7 in Monitor (cx=0x8360a68, entryFrame=0xf7702020, interpMode=js::JSINTERP_NORMAL) at ../jsinferinlines.h:622
#4  js::Interpret (cx=0x8360a68, entryFrame=0xf7702020, interpMode=js::JSINTERP_NORMAL) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:1915
#5  0x081d6e69 in js::mjit::EnterMethodJIT (cx=0x8360a68, fp=0xf7702020, code=0xf74cf050, stackLimit=0xf7ae2000, partial=false) at /srv/repos/mozilla-central/js/src/methodjit/MethodJIT.cpp:1074
#6  0x081d6fc3 in CheckStackAndEnterMethodJIT (cx=0x8360a68, partial=false) at /srv/repos/mozilla-central/js/src/methodjit/MethodJIT.cpp:1109
#7  js::mjit::JaegerShot (cx=0x8360a68, partial=false) at /srv/repos/mozilla-central/js/src/methodjit/MethodJIT.cpp:1121


and on Valgrind I see lots of errors with the opt-build indicating some corruption (see attached Valgrind log). Marking s-s because of that until investigated.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: patch

This found two bugs.

The first one is that JSCompartment::emptyTypeObject needs a read barrier because it's a weak pointer.

The other problem is that we weren't correctly resetting the incremental GC when a new compartment was added in the middle. The sequence of events looks like this:

First GC slice:
  Collect only compartment A

Second GC slice: triggered by TOO_MUCH_MALLOC in compartment B
  Schedule compartments A and B for collection
    (since A was collected before, and B was the trigger)
  Call BudgetIncrementalGC
    Notice that tooMuchMalloc() is true for B, so set the budget to
      unlimited and return

If we hadn't returned early, we also would have noticed that compartment B was not collected in the first slice, and we would have called ResetIncrementalGC. That's the bug.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/edf797d10aa0

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/mozilla-central/rev/edf797d10aa0

Comment 4

[Daniel Veditz [:dveditz]]

The incremental GC part doesn't affect the ESR-10 branch, but what about the emptyTypeObject bug? Is that a "regression" from a more recent feature too, or an older problem?

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This bug only hits if incremental GC is enabled.

Comment 6

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 8

[Christian Holler (:decoder)]

A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug754242.js.