Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Assertion failure: allocated(), at ../../gc/Heap.h:497 or Crash [@ js::gc::Arena::isAligned]

RESOLVED FIXED in mozilla16



JavaScript Engine
5 years ago
5 years ago


(Reporter: decoder, Assigned: billm)


(Blocks: 1 bug, {assertion, crash, testcase})

assertion, crash, testcase
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [js:p2], crash signature)


(1 attachment)



5 years ago
The following test asserts/crashes on mozilla-central revision 75d817e6bf4d (options -m -n -a):

var summary = '';
function printStatus (msg) {
  var lines = msg.split ("\n");
function f() {\
    var ss = [\
        new f(Int8Array, propertyIsEnumerable, '[let (x = 3, y = 4) x].map(0)')\
try {\
} catch (e) {}\
  printStatus (summary);\
function g(n, h) {\
    var a = f;\
    if (n <= 0) \
    return f; \
    var t = g(n - 1, h);\
    var r = function(x) {    };\
g(80, f);\

Stepping through the assertion triggers some more and then crashes with SIGFPE (division by 0):

Program received signal SIGFPE, Arithmetic exception.
0x080fca5f in js::gc::Arena::isAligned (thing=4149285072, thingSize=0) at ../gc/Heap.h:574
574             return tailOffset % thingSize == 0;
(gdb) bt
#0  0x080fca5f in js::gc::Arena::isAligned (thing=4149285072, thingSize=0) at ../gc/Heap.h:574
#1  0x083127a9 in js::gc::Cell::isAligned (this=0xf75110d0) at ../gc/Heap.h:976
#2  0x0831a362 in js::gc::CheckMarkedThing<JSObject> (trc=0x8620b50, thing=0xf75110d0) at /srv/repos/mozilla-central/js/src/gc/Marking.cpp:89
#3  0x08318abb in js::gc::MarkInternal<JSObject> (trc=0x8620b50, thingp=0xffffb61c) at /srv/repos/mozilla-central/js/src/gc/Marking.cpp:103
#4  0x08313972 in js::gc::MarkKind (trc=0x8620b50, thingp=0xffffb61c, kind=JSTRACE_OBJECT) at /srv/repos/mozilla-central/js/src/gc/Marking.cpp:233
#5  0x08313e60 in js::gc::MarkValueInternal (trc=0x8620b50, v=0xf7704640) at /srv/repos/mozilla-central/js/src/gc/Marking.cpp:329
#6  0x08313f80 in js::gc::MarkValueRoot (trc=0x8620b50, v=0xf7704640, name=0x8479356 "vm_stack") at /srv/repos/mozilla-central/js/src/gc/Marking.cpp:349
#7  0x0829f399 in js::StackSpace::markFrameSlots (this=0x85f9b50, trc=0x8620b50, fp=0xf77045f0, slotsEnd=0xf7704650, pc=0x8620c9f "W") at /srv/repos/mozilla-central/js/src/vm/Stack.cpp:492
#8  0x0829f517 in js::StackSpace::mark (this=0x85f9b50, trc=0x8620b50) at /srv/repos/mozilla-central/js/src/vm/Stack.cpp:527
#9  0x08102f23 in js::MarkRuntime (trc=0x8620b50, useSavedRoots=false) at /srv/repos/mozilla-central/js/src/jsgc.cpp:2322
#10 0x081077a2 in js::gc::StartVerifyBarriers (rt=0x85f9b28) at /srv/repos/mozilla-central/js/src/jsgc.cpp:4254
#11 0x0810805d in js::gc::MaybeVerifyBarriers (cx=0x861dd50, always=false) at /srv/repos/mozilla-central/js/src/jsgc.cpp:4433
#12 0x0815653f in js::Interpret (cx=0x861dd50, entryFrame=0xf7702088, interpMode=js::JSINTERP_NORMAL) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:3283

The opt build is all happy with the test, but I'm marking s-s anyway until this is confirmed to be debug-only/harmless, since it seems that there is something wrong with alignment. Before reduction, the test had this assertion which later didn't show up anymore:

Assertion failure: thing->isAligned(), at gc/Marking.cpp:89


5 years ago
Assignee: general → wmccloskey
Whiteboard: js-triage-needed → [js:investigate][js:ni]
Whiteboard: [js:investigate][js:ni] → [js:p1:fx16][js:investigate][js:ni]
Whiteboard: [js:p1:fx16][js:investigate][js:ni] → [js:p1:fx15][js:investigate][js:ni]

Comment 1

5 years ago
Created attachment 623390 [details] [diff] [review]

This is another exact stack scanning bug, although I think it's a debug-only problem.

We execute bytecode that looks like this:
00046:  lambda (function (x) {})
00051:  setlocal 2

Currently, the write barrier verifier is called at the beginning of every op in the interpreter, before any code runs for it. However, at that time the JSOP_SETLOCAL code hasn't had a chance to write to slot #2 yet. So we crash when we scan the stack and see bad data in slot #2, which it thinks is live.

This patch moves the write barrier verifier call so that it happens at the end of the op, rather than at the beginning. I'm a little worried that this will just expose other cases where we behave badly. So I added some stack poisoning code that should make it easier for the fuzzers to catch these bugs. I'm pretty sure that the poisoning shouldn't affect register allocation, so hopefully the semantics of the code won't change (aside from the stack slots getting poisoned).
Attachment #623390 - Flags: review?(bhackett1024)
Comment on attachment 623390 [details] [diff] [review]

Review of attachment 623390 [details] [diff] [review]:

::: js/src/methodjit/Compiler.cpp
@@ +1224,5 @@
>          if (lifetime)
>              masm.storeValue(UndefinedValue(), local);
> +#ifdef DEBUG
> +        else
> +            masm.storeValue(ObjectValue(*reinterpret_cast<JSObject *>(0x42)), local);

How about adding an ObjectValueCrashOnTouch()?

@@ +1243,5 @@
> +#ifdef DEBUG
> +    uint32_t depth = ssa.getFrame(a->inlineIndex).depth;
> +    for (uint32_t i = script->nfixed; i < script->nslots; i++) {
> +        Address local(JSFrameReg, sizeof(StackFrame) + (depth + i) * sizeof(Value));
> +        masm.storeValue(ObjectValue(*reinterpret_cast<JSObject *>(0x42)), local);

Attachment #623390 - Flags: review?(bhackett1024) → review+

Comment 3

5 years ago
Group: core-security

Comment 4

5 years ago

This had tons of orange.
Whiteboard: [js:p1:fx15][js:investigate][js:ni] → [js:p2][js:ni]

Comment 5

5 years ago
Target Milestone: --- → mozilla15

Comment 6

5 years ago
I had to back this out again because it was turning windows debug builds purple during "make check". FML.

Comment 7

5 years ago
Target Milestone: mozilla15 → mozilla16

Comment 8

5 years ago
Last Resolved: 5 years ago
Resolution: --- → FIXED


5 years ago
Duplicate of this bug: 764416


5 years ago
Blocks: 782782
Whiteboard: [js:p2][js:ni] → [js:p2]

Comment 10

5 years ago
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug753283.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.