The default bug view has changed. See this FAQ.

Assertion failure: array, at ../jsanalyze.h:1032 or Crash [@ js::types::TypeSet::baseFlags]

RESOLVED FIXED in mozilla10

Status

()

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

People

(Reporter: decoder, Assigned: bhackett)

Tracking

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

Trunk
mozilla10
x86
Linux
assertion, crash, testcase
Points:
---

Firefox Tracking Flags

(firefox7 unaffected, firefox8 unaffected)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 566490 [details]
shell testcase, unpack, chdir and run main.js with options "-n -m"

The attached test asserts on mozilla-central revision (options -m -n), tested with 32 bit. 

Warning: an OOM is involved, I did not check the memory consumption.

When stepping through the assert on 32 bit, I get this crash:

Program received signal SIGSEGV, Segmentation fault.
0x0809caf8 in js::types::TypeSet::baseFlags (this=0x0) at /srv/repos/mozilla-central/js/src/jsinfer.h:371
371         TypeFlags baseFlags() const { return flags & TYPE_FLAG_BASE_MASK; }
(gdb) bt
#0  0x0809caf8 in js::types::TypeSet::baseFlags (this=0x0) at /srv/repos/mozilla-central/js/src/jsinfer.h:371
#1  0x08120522 in js::types::TypeSet::getKnownTypeTag (this=0x0, cx=0x8504b00) at /srv/repos/mozilla-central/js/src/jsinfer.cpp:1471
#2  0x0833ced7 in js::mjit::Compiler::knownPushedType (this=0xffff7848, pushed=0) at /srv/repos/mozilla-central/js/src/methodjit/Compiler.cpp:7260
#3  0x08335679 in js::mjit::Compiler::jsop_this (this=0xffff7848) at /srv/repos/mozilla-central/js/src/methodjit/Compiler.cpp:5629
#4  0x08327450 in js::mjit::Compiler::generateMethod (this=0xffff7848) at /srv/repos/mozilla-central/js/src/methodjit/Compiler.cpp:2143
#5  0x0831f49b in js::mjit::Compiler::performCompilation (this=0xffff7848, jitp=0xf74055d8) at /srv/repos/mozilla-central/js/src/methodjit/Compiler.cpp:536
#6  0x0831e44b in js::mjit::Compiler::compile (this=0xffff7848) at /srv/repos/mozilla-central/js/src/methodjit/Compiler.cpp:164
#7  0x0831fb46 in js::mjit::TryCompile (cx=0x8504b00, script=0xf7405550, construct=false) at /srv/repos/mozilla-central/js/src/methodjit/Compiler.cpp:643
#8  0x0813b381 in js::mjit::CanMethodJIT (cx=0x8504b00, script=0xf7405550, construct=false, request=js::mjit::CompileRequest_Interpreter)
    at /srv/repos/mozilla-central/js/src/methodjit/MethodJIT-inl.h:79
#9  0x081532b8 in js::Interpret (cx=0x8504b00, entryFrame=0xf76e90d8, interpMode=js::JSINTERP_NORMAL) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:4033


On 64 bit, I only get this assertion:

Assertion failure: nesting->activeFrames != 0, at jsinfer.cpp:5326


S-s because I cannot rate the exact impact of this. With different asserts and OOM involved, this might crash in different places.
Is this a regression since Fx9 or has it always been in since TI landed?

The 32-bit crash looks null-deref-ish, but higher in the stack this=0xffff7848 doesn't look good.
status-firefox10: --- → affected
status-firefox7: --- → unaffected
status-firefox8: --- → unaffected
array is NULL here:

        types::TypeSet *array = getCode(offset).pushedTypes;
        JS_ASSERT(array);
        return array + which;

Given |array + which|, seems potentially unsafe. Brian, what do you think?
Whiteboard: js-triage-needed → sg:critical
>         types::TypeSet *array = getCode(offset).pushedTypes;

Changed in http://hg.mozilla.org/mozilla-central/diff/772f0b507d01/js/src/jsanalyze.h

>         JS_ASSERT(array);
>         return array + which;

Changed earlier than the above line in http://hg.mozilla.org/mozilla-central/diff/90a7b141e0cf/js/src/jsanalyze.h
(Reporter)

Comment 4

6 years ago
It seems that I forgot to include the revision I tested this on. It should be mozilla-central revision 866b2b1793cd.
Created attachment 566877 [details] [diff] [review]
patch

'which' is restricted to the maximum number of values which an opcode can push, which is 2 (pushedTypes isn't used for ENTERBLOCK, which can push up to 2^^16 slots).  So this should just be a NULL or near-NULL deref.

The OOM happened during analysis (the test sets the maxBytes gcparam to a small number; it would be good to do testing with a low maxBytes to catch more OOM errors).  This caused inference to bail out and trigger nuking of type information in the compartment, but the failure was not correctly reported to the compiler so it proceeded to try compiling against the incomplete type information for the script.
Assignee: general → bhackett1024
Attachment #566877 - Flags: review?(dvander)
Attachment #566877 - Flags: review?(dvander) → review+
Unhiding per comment 5.
Group: core-security
Whiteboard: sg:critical
https://hg.mozilla.org/integration/mozilla-inbound/rev/59bf7d250aa0
https://hg.mozilla.org/mozilla-central/rev/59bf7d250aa0
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10

Updated

5 years ago
status-firefox10: affected → ---
You need to log in before you can comment on or make changes to this bug.