Last Comment Bug 693961 - Assertion failure: array, at ../jsanalyze.h:1032 or Crash [@ js::types::TypeSet::baseFlags]
: Assertion failure: array, at ../jsanalyze.h:1032 or Crash [@ js::types::TypeS...
: assertion, crash, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Linux
-- critical (vote)
: mozilla10
Assigned To: Brian Hackett (:bhackett)
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: langfuzz
  Show dependency treegraph
Reported: 2011-10-12 04:12 PDT by Christian Holler (:decoder)
Modified: 2012-01-20 09:45 PST (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

shell testcase, unpack, chdir and run main.js with options "-n -m" (2.48 KB, application/x-compressed-tar)
2011-10-12 04:12 PDT, Christian Holler (:decoder)
no flags Details
patch (648 bytes, patch)
2011-10-13 10:26 PDT, Brian Hackett (:bhackett)
dvander: review+
Details | Diff | Splinter Review

Description User image Christian Holler (:decoder) 2011-10-12 04:12:00 PDT
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.
Comment 1 User image Daniel Veditz [:dveditz] 2011-10-12 16:14:25 PDT
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.
Comment 2 User image David Mandelin [:dmandelin] 2011-10-12 17:55:25 PDT
array is NULL here:

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

Given |array + which|, seems potentially unsafe. Brian, what do you think?
Comment 3 User image Gary Kwong [:gkw] [:nth10sd] 2011-10-12 18:09:32 PDT
>         types::TypeSet *array = getCode(offset).pushedTypes;

Changed in

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

Changed earlier than the above line in
Comment 4 User image Christian Holler (:decoder) 2011-10-13 10:04:17 PDT
It seems that I forgot to include the revision I tested this on. It should be mozilla-central revision 866b2b1793cd.
Comment 5 User image Brian Hackett (:bhackett) 2011-10-13 10:26:03 PDT
Created attachment 566877 [details] [diff] [review]

'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.
Comment 6 User image David Mandelin [:dmandelin] 2011-10-13 17:49:55 PDT
Unhiding per comment 5.
Comment 7 User image Brian Hackett (:bhackett) 2011-10-17 14:19:17 PDT
Comment 8 User image Marco Bonardo [::mak] 2011-10-18 05:37:43 PDT

Note You need to log in before you can comment on or make changes to this bug.