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...
Status: RESOLVED FIXED
fixed-in-jaegermonkey
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- critical (vote)
: ---
Assigned To: general
:
: Jason Orendorff [:jorendorff]
Mentors:
: 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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


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

Description 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){ 
	with(this) 
	for(var x in o) 
	printStatus(o[x]); 
}
f2([]);
Comment 1 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 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 Brian Hackett (:bhackett) 2011-09-02 18:55:14 PDT
Created attachment 558013 [details] [diff] [review]
patch

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 Brian Hackett (:bhackett) 2011-09-03 06:50:25 PDT
*** Bug 684474 has been marked as a duplicate of this bug. ***
Comment 5 Brian Hackett (:bhackett) 2011-09-04 13:42:17 PDT
http://hg.mozilla.org/projects/jaegermonkey/rev/53e25966f155
Comment 6 Brian Hackett (:bhackett) 2011-09-06 22:39:01 PDT
http://hg.mozilla.org/mozilla-central/rev/53e25966f155
Comment 7 [PTO to Dec5] Bill McCloskey (:billm) 2011-09-19 11:19:02 PDT
Comment on attachment 558013 [details] [diff] [review]
patch

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 Christian Holler (:decoder) 2013-01-19 14:10:12 PST
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929

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