Crash [@ js::types::UseNewTypeForClone] or [@ JSScript::hasBaselineScript] or [@ js::ion::DoCallFallback]

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: gkw, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, 4 keywords)

Trunk
x86_64
Mac OS X
crash, regression, sec-high, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox25 unaffected, firefox26 affected, firefox-esr17 unaffected, firefox-esr24 unaffected, b2g18 unaffected)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 786631 [details]
testcase

The attached fairly-reduced testcase crashes js threadsafe 64-bit debug and opt shell on m-c changeset 1fb5d14e8348 with --ion-parallel-compile=on --ion-eager at js::types::UseNewTypeForClone

The more this gets reduced, the more unreliable it is, so attaching as-is.

Setting s-s just-in-case, this seems to be a null-deref at first glance, but I'm not sure.
(Reporter)

Comment 1

5 years ago
Created attachment 786632 [details]
debug and opt stacks
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:bisect]
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
(Reporter)

Comment 3

5 years ago
I definitely reproduce on a threadsafe shell, trying to get a bisection range now.
Whiteboard: [jsbugmon:bisect]
(Reporter)

Comment 4

5 years ago
Due to skipped revisions, the first bad revision could be any of:
changeset:   http://hg.mozilla.org/mozilla-central/rev/7d4e75a5d414
user:        Nicolas B. Pierron
date:        Mon Aug 05 18:09:19 2013 -0700
summary:     Bug 901178 - IonMonkey: Avoid parsing unused lambda functions. r=bhackett

changeset:   http://hg.mozilla.org/mozilla-central/rev/65cd9cfc65c3
user:        Timothy Nikkel
date:        Mon Aug 05 23:32:23 2013 -0500
summary:     Bug 896053. Unlink sibling/child lists of widgets for nsCocoaWindow's correctly. r=smichaud

Probably bug 901178?
Blocks: 901178
Flags: needinfo?(nicolas.b.pierron)
(Reporter)

Updated

5 years ago
status-firefox22: --- → unaffected
status-firefox23: --- → unaffected
status-firefox24: --- → unaffected
status-firefox25: --- → unaffected
status-firefox26: --- → affected
status-firefox-esr17: --- → unaffected
tracking-firefox26: --- → ?
(Reporter)

Updated

5 years ago
Crash Signature: [@ js::types::UseNewTypeForClone] → [@ js::types::UseNewTypeForClone] [@ JSScript::hasBaselineScript] [@ js::ion::DoCallFallback]
Summary: Crash [@ js::types::UseNewTypeForClone] → Crash [@ js::types::UseNewTypeForClone] or [@ JSScript::hasBaselineScript] or [@ js::ion::DoCallFallback]
(Reporter)

Comment 6

5 years ago
This should be fixed after the backout for bug 901178 hits m-c.
Gary, can verify that this is fixed now?
Keywords: sec-high
(Reporter)

Comment 8

5 years ago
Yes, I just retested and the testcases in this bug are likely fixed by the backout.
status-firefox26: affected → fixed
Flags: needinfo?(nicolas.b.pierron)
(Reporter)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
tracking-firefox26: ? → ---
Should we land the test for this?
Flags: in-testsuite?
Target Milestone: --- → mozilla26
Since this is Trunk only, yes.
(Reporter)

Comment 11

5 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #9)
> Should we land the test for this?

Only the test in comment 0 should be landed, if necessary.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #9)
> Should we land the test for this?

Not if we cannot reproduce it in a deterministic way.  At the moment the original patch has been backed out.  And, as part of bug 902690, I am close to get a test case which can reproduce this issue at 100%.

The test would be useless so far, because the shell does not run with parallel compilation on by default, and we should fix that too, by running fake scheduling compilation for most of the test suite, such as we can reproduce these kind of issues.
status-firefox22: unaffected → ---
status-firefox23: unaffected → ---
status-firefox24: unaffected → ---
status-firefox26: fixed → affected
status-firefox-esr17: unaffected → ---
Target Milestone: mozilla26 → ---
Nicolas, did you clear all of my flags, including ESR, for a reason?
status-firefox-esr17: --- → unaffected
status-firefox-esr24: --- → unaffected
(In reply to Al Billings [:abillings] from comment #13)
> Nicolas, did you clear all of my flags, including ESR, for a reason?

One day I would have to figure out the reason behind that, but this is not the first time it happened to me.
Sorry :/

This bug is fixed because of the backout and Brian landed another version of the JSOP_LAMBDA optim.
Session restored tabs have, historically, sometimes reset flags if you then save.
status-b2g18: --- → unaffected
Group: core-security
You need to log in before you can comment on or make changes to this bug.