827821 - IonMonkey: Assertion failure: type == MIRType_Boolean || type == MIRType_Int32 || type == MIRType_Double || type == MIRType_String || type == MIRType_Object, at ion/MIR.h:1557

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 795632f0e4fe (run with --ion-eager):


var lfcode = new Array();
lfcode.push("3");
lfcode.push("\
	gczeal(2);\
	for (let q = 0; q < 50; ++q) {\
		var w = \"r\".match(/r/);\
	}\
	let (eval) (function  (a) {\
		Function = gczeal;\
	})();\
	// .js\
");
lfcode.push(" // .js");
lfcode.push(" // .js");
lfcode.push(" // .js");
while (true) {
	var file = lfcode.shift(); if (file == undefined) { break; }
        loadFile(file)
}
function loadFile(lfVarx) {
    try {
        if (lfVarx.substr(-3) == ".js") {
	    uneval("foo");
            switch (lfRunTypeId) {
                case 3: function newFunc(x) { new Function(x)(); }; newFunc(lfVarx); break;
                case 4: eval("(function() { " + lfVarx + " })();"); break;
            }
        } else if (!isNaN(lfVarx)) {
            lfRunTypeId = parseInt(lfVarx);
	}
    } catch (lfVare) {}
}

Comment 1

[Christian Holler (:decoder)]

Marked s-s because this involves gczeal and looks like it could be some sort of type mismatch.

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   117618:67e44e98555c
user:        Hannes Verschore
date:        Fri Jan 04 17:11:32 2013 +0100
summary:     Bug 825705: Creating this on caller-side shouldn't query prototype for unknown objects, r=jandem

This iteration took 75.578 seconds to run.

Comment 3

[Christian Holler (:decoder)]

Needinfo from Hannes, based on comment 2 :)

Comment 4

[Christian Holler (:decoder)]

Got a similar one  with the same assert but that crashes in js::ion::LIRGeneratorX86::visitUnbox with a write to a null address.

Comment 5

[Hannes Verschore [:h4writer]]

Attachment: Handle JSVAL_TYPE_MAGIC in pushTypeBarrier

Sorry about the delay, but I was on vacation.

The problem here is that pushTypeBarrier doesn't handle "JSVAL_TYPE_MAGIC" correctly and tries to unbox it. (What is impossible in IM.). The added code should handle that. Fixes the asserts.

Comment 7

[Hannes Verschore [:h4writer]]

Attachment: Create this at callee side, when failing at caller side

Previous patch was merely fighting symptoms. This is the real deal. During the VMCall we need to create this at callee side if it failed / is impossible at caller side.

Comment 8

[Christian Holler (:decoder)]

Based on discussion with Hannes on IRC, this bug can only lead to crashes due to reads/writes near null. Removing s-s.

Comment 9

[Jan de Mooij [:jandem]]

Comment on attachment 701850 [details] [diff] [review]
Create this at callee side, when failing at caller side

Review of attachment 701850 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the testcases in comment 0 and bug 827882 comment 0 added to jit-tests.

Comment 10

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Jan de Mooij [:jandem] from comment #9)
> Comment on attachment 701850 [details] [diff] [review]
> Create this at callee side, when failing at caller side
> 
> Review of attachment 701850 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r=me with the testcases in comment 0 and bug 827882 comment 0 added to
> jit-tests.

You might want to add bug 827882 comment 5 as well. It crashes and asserts, whereas the one in comment 0 only asserts.

Comment 11

[Hannes Verschore [:h4writer]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6c1387877737

Comment 12

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/6c1387877737

Comment 13

[Hannes Verschore [:h4writer]]

Comment on attachment 701850 [details] [diff] [review]
Create this at callee side, when failing at caller side

[Approval Request Comment]
Bug caused by (feature/regressing bug #): #825705

User impact if declined: Possible crashes at 0x0 - 0x11

Testing completed (on m-c, etc.): m-c for a week, testcases fixed

Risk to taking this patch (and alternatives if risky): 
Low. The fix is using a code path that used to get taken before the changes in #825705. Well tested in FF18 and FF19.

String or UUID changes made by this patch: /

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 701850 [details] [diff] [review]
Create this at callee side, when failing at caller side

approving low risk fix for aurora to help mitigate potential crashes.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/90839133382e

Comment 16

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/2e891e0db397