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

RESOLVED FIXED in mozilla16

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: decoder, Assigned: billm)

Tracking

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

Trunk
mozilla16
x86
Linux
assertion, crash, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

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");
}
evaluate("\
function f() {\
    var ss = [\
        new f(Int8Array, propertyIsEnumerable, '[let (x = 3, y = 4) x].map(0)')\
    ];\
}\
try {\
    f();\
} catch (e) {}\
  gczeal(4);\
  printStatus (summary);\
");
evaluate("\
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
(Assignee)

Updated

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]
(Assignee)

Comment 1

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

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]
patch

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);

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

Comment 3

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/20619d227f29
Group: core-security
(Assignee)

Comment 4

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/ee9e7fe2c448

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

Comment 5

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/49b7aa3593de
Target Milestone: --- → mozilla15
(Assignee)

Comment 6

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/385cbb1d800f
(Assignee)

Comment 7

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/8d857c53bc0a
Target Milestone: mozilla15 → mozilla16

Comment 8

5 years ago
https://hg.mozilla.org/mozilla-central/rev/8d857c53bc0a
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Duplicate of this bug: 764416
(Assignee)

Updated

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

Comment 10

4 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.