Last Comment Bug 684281 - Assertion failure: [infer failure] Missing type in object [0x7fc592604680] (index): int, at jsinfer.cpp:341
: Assertion failure: [infer failure] Missing type in object [0x7fc592604680] (i...
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
-- critical (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
: 684474 (view as bug list)
Depends on:
Blocks: infer-regress langfuzz
  Show dependency treegraph
Reported: 2011-09-02 10:30 PDT by Christian Holler (:decoder)
Modified: 2013-01-19 14:10 PST (History)
4 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (4.47 KB, patch)
2011-09-02 18:55 PDT, Brian Hackett (:bhackett)
wmccloskey: review+
Details | Diff | Splinter Review

Description User image Christian Holler (:decoder) 2011-09-02 10:30:30 PDT
The following testcase asserts on mozilla-central revision fcca99426576 (run with -m -n -a), tested on 64 bit:

function printStatus (msg) {}
F = function () {};
F.prototype = new Int32Array(1);
o = new F();
function f2(o){ 
	for(var x in o) 
Comment 1 User image Christian Holler (:decoder) 2011-09-02 10:35:54 PDT
One more question to this test: I remember that at some point, infer failures were critical, as in, we cannot continue, therefore we abort (either through assertion or controlled crash, which we changed a while ago). This test doesn't do anything for optimized builds, is that intended behavior?
Comment 2 User image Brian Hackett (:bhackett) 2011-09-02 11:15:09 PDT
The [infer failure] generally reflects that the core TI invariant, that the known types reflect the state of the world, is violated.  It does not mean we will crash later, but if we *do* crash it will probably be hard to track down the underlying cause.
Comment 3 User image Brian Hackett (:bhackett) 2011-09-02 18:55:14 PDT
Created attachment 558013 [details] [diff] [review]

Bogus assert.  Property type sets are not correct for objects with a class getter op, but we would still assert correctness for accesses on native objects which inherit properties from such objects.

Most of this patch is fixing Diassemble so that it can be called while iterating over scripts (and which I noticed while investigating this).  This broke after the recent CellIter changes in the GC (though I think that CellIter was correct to break this, as Disassemble shouldn't be allocating GC things while traversing arenas).
Comment 4 User image Brian Hackett (:bhackett) 2011-09-03 06:50:25 PDT
*** Bug 684474 has been marked as a duplicate of this bug. ***
Comment 5 User image Brian Hackett (:bhackett) 2011-09-04 13:42:17 PDT
Comment 6 User image Brian Hackett (:bhackett) 2011-09-06 22:39:01 PDT
Comment 7 User image Bill McCloskey (:billm) 2011-09-19 11:19:02 PDT
Comment on attachment 558013 [details] [diff] [review]

I guess this landed already.

It would be nice if there were a better way to do this, but I can't think of any.
Comment 8 User image Christian Holler (:decoder) 2013-01-19 14:10:12 PST
Automatically extracted testcase for this bug was committed:

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