Note: There are a few cases of duplicates in user autocompletion which are being worked on.

TM: "Assertion failed: LIR type error (start of writer pipeline): arg 1 of 'fmul' is 'int' which has type int32 (expected float64): 0 (../nanojit/LIR.cpp" or "Assertion failure: m != TT_INT32 || isInt32(*vp), at ../jstracer.cpp"

VERIFIED FIXED

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
7 years ago
5 years ago

People

(Reporter: gkw, Assigned: Robert Sayre)

Tracking

(Blocks: 1 bug, {assertion, regression, testcase})

Trunk
x86
Mac OS X
assertion, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 beta1+, blocking1.9.2 .11+, status1.9.2 .11-fixed, status1.9.1 unaffected)

Details

(Whiteboard: [sg:critical?]fixed-in-tracemonkey)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
x = true;
(function() {
  for each(let c in [0, x]) {
    (arguments)[4] *= c
  }
})()

asserts js debug shell on JM tip with -m and -j at Assertion failed: LIR type error (start of writer pipeline): arg 1 of 'fmul' is 'int' which has type int32 (expected float64): 0 (../nanojit/LIR.cpp:2610)
(Reporter)

Comment 1

7 years ago
A variant testcase asserts differently:

var c;
(function() {
  for each(e in [0, 0]) {
    (arguments)[1] *= c
  }
})()


Assertion failure: m != TT_INT32 || isInt32(*vp), at ../jstracer.cpp:3796
Summary: JM: "Assertion failed: LIR type error (start of writer pipeline): arg 1 of 'fmul' is 'int' which has type int32 (expected float64): 0 (../nanojit/LIR.cpp" → JM: "Assertion failed: LIR type error (start of writer pipeline): arg 1 of 'fmul' is 'int' which has type int32 (expected float64): 0 (../nanojit/LIR.cpp" or "Assertion failure: m != TT_INT32 || isInt32(*vp), at ../jstracer.cpp"
This affects tm-tip too.
No longer blocks: 549412
Summary: JM: "Assertion failed: LIR type error (start of writer pipeline): arg 1 of 'fmul' is 'int' which has type int32 (expected float64): 0 (../nanojit/LIR.cpp" or "Assertion failure: m != TT_INT32 || isInt32(*vp), at ../jstracer.cpp" → TM: "Assertion failed: LIR type error (start of writer pipeline): arg 1 of 'fmul' is 'int' which has type int32 (expected float64): 0 (../nanojit/LIR.cpp" or "Assertion failure: m != TT_INT32 || isInt32(*vp), at ../jstracer.cpp"
Yuck. The problem is that the tracer expects arguments[n] to be undefined if |n| is out of range. In this case, it is _not_ undefined, it is NaN, because the interpreter did this:

  arguments[4] = undefined * 0
Group: core-security
(Reporter)

Comment 4

7 years ago
You're right - it occurs on TM tip with -j. In the past, it used to assert at:

Assertion failed: ((unsigned)r)<8 (../nanojit/Nativei386.cpp:427)

or

Assertion failed: s0->isQuad() && s1->isQuad() (../nanojit/LIR.cpp:2182)

before morphing to the current form.

autoBisect shows this is probably related to bug 453730:

The first bad revision is:
changeset:   30020:c76558a87dd9
user:        David Mandelin
date:        Wed Jul 08 11:16:41 2009 -0700
summary:     Bug 453730: trace JSOP_ARGUMENTS, r=gal
Blocks: 453730
(Reporter)

Updated

7 years ago
blocking1.9.2: --- → ?
blocking2.0: --- → ?
(Assignee)

Updated

7 years ago
Assignee: general → dmandelin
(Assignee)

Updated

7 years ago
blocking2.0: ? → beta1+
blocking1.9.2: ? → ---
status1.9.2: --- → wanted
Whiteboard: [sg:critical?]
dvander and I talked this over, and we think all that it takes to fix this is to abort tracing a getelem with arguments (args[expr]) if the index is a constant that is out of range. The tracer already aborts if the index is a non-constant that is out of range, so this just makes things consistent. 

ETA = patch up for review later today.
Created attachment 437988 [details] [diff] [review]
Patch
Attachment #437988 - Flags: review?(jorendorff)
Adding bug 547299 as a dep because it needs to land on 1.9.2 before the patch for this bug can land there.
Depends on: 547299
Attachment #437988 - Attachment is patch: true
Attachment #437988 - Attachment mime type: application/x-javascript → text/plain
Attachment #437988 - Flags: review?(jorendorff) → review+
Comment on attachment 437988 [details] [diff] [review]
Patch

The patch looks good.

Please put newlines on the last line of the two test files.
http://hg.mozilla.org/tracemonkey/rev/bbdddef55da3
Whiteboard: [sg:critical?] → [sg:critical?]fixed-in-tracemonkey
(Assignee)

Comment 10

7 years ago
http://hg.mozilla.org/mozilla-central/rev/bbdddef55da3
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(In reply to comment #7)
> Adding bug 547299 as a dep because it needs to land on 1.9.2 before the patch
> for this bug can land there.

That one's fixed in 1.9.2.4, please add a 1.9.2 patch for this bug (or request approval on the trunk patch if it applies)
blocking1.9.2: --- → needed
blocking1.9.2: needed → .10+
status1.9.1: --- → unaffected

Updated

7 years ago
Assignee: dmandelin → sayrer
Why did this just land on 1.9.2 without approval? This isn't a new policy, and I've said this before. All branch patches must have explicit approval before landing. blocking+ is not enough.
Attachment #437988 - Flags: approval1.9.2.11?
(Assignee)

Comment 13

7 years ago
(In reply to comment #12)
> Why did this just land on 1.9.2 without approval? This isn't a new policy, and
> I've said this before. All branch patches must have explicit approval before
> landing. blocking+ is not enough.

It's set to blocking 1.9.2.11. I don't even know why am answering this nonsense.
(Assignee)

Comment 14

7 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2c360dcaf7d5
status1.9.2: wanted → .11-fixed

Updated

7 years ago
Attachment #437988 - Flags: approval1.9.2.11? → approval1.9.2.11+
Group: core-security
Tracer has been long gone on trunk, marking verified.
Status: RESOLVED → VERIFIED
A testcase for this bug was automatically identified at js/src/jit-test/tests/arguments/bug554670-1.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.