Last Comment Bug 746397 - IonMonkey: Assertion failure: unexpected type, at ion/Lowering.cpp:822
: IonMonkey: Assertion failure: unexpected type, at ion/Lowering.cpp:822
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Other Branch
: x86_64 Linux
: -- major (vote)
: ---
Assigned To: Kannan Vijayan [:djvj]
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: langfuzz IonFuzz
  Show dependency treegraph
Reported: 2012-04-17 16:27 PDT by Christian Holler (:decoder)
Modified: 2013-02-07 05:13 PST (History)
7 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Fix (445 bytes, patch)
2012-04-30 13:08 PDT, Kannan Vijayan [:djvj]
dvander: review+
Details | Diff | Splinter Review
FIX: Better diff with more context (660 bytes, patch)
2012-04-30 13:11 PDT, Kannan Vijayan [:djvj]
dvander: review+
Details | Diff | Splinter Review

Description Christian Holler (:decoder) 2012-04-17 16:27:01 PDT
The following testcase asserts on ionmonkey revision 67bf9a4a1f77 (run with --ion -n -m --ion-eager):

(function () {
  var a = ['x', 'y'];[+("0")], counter);
Comment 1 Christian Holler (:decoder) 2012-04-19 15:28:59 PDT
JSBugMon: The testcase found in this bug no longer reproduces (tried revision de015aff650d).
Comment 2 Christian Holler (:decoder) 2012-04-23 06:17:55 PDT
The test here broke because bug
Comment 3 Christian Holler (:decoder) 2012-04-23 06:19:04 PDT
Yea.. because bug...  because bug 724751 removed the --ion, -n and -m options. It probably would have been better to keep them without any action such that automation doesn't break.
Comment 4 Christian Holler (:decoder) 2012-04-23 06:39:32 PDT
JSBugMon: This bug has been automatically confirmed to be still valid (reproduced on revision 9e64f779b611).
Comment 5 Kannan Vijayan [:djvj] 2012-04-30 13:08:57 PDT
Created attachment 619657 [details] [diff] [review]

The issue here is simple: IonBuilder's handling of jsop_pos tries to optimize the case when the input is an int32 by leaving the input as-is.

However, when checking for this case, it checks the 'rval' (result value) typeset for the jsop_pos operation instead of the 'ival' (input value) typeset.  The rval typeset for jsop_pos is optimistically initialized to INT32.  This devolves into a ToInt32 of a string in MIR, which triggers an assert because the LIRGenerator doesn't yet handle compiled String->Int32 conversions.
Comment 6 Kannan Vijayan [:djvj] 2012-04-30 13:11:37 PDT
Created attachment 619659 [details] [diff] [review]
FIX: Better diff with more context

The previous diff was barebones.  This is the same patch, but with more patch context and function names present.
Comment 7 Kannan Vijayan [:djvj] 2012-05-01 08:31:58 PDT
Comment 8 Christian Holler (:decoder) 2013-02-07 05:13:24 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.