"Assertion failure: !tc->inStrictMode(),"

RESOLVED FIXED in Firefox -esr10

Status

()

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

People

(Reporter: gkw, Assigned: evilpie)

Tracking

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

Trunk
mozilla11
x86
Mac OS X
assertion, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr1012+ verified)

Details

(Whiteboard: [qa+:ashughes])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 569518 [details]
stack

Reflect.parse("\"use strict\";*")

asserts js debug shell on m-c changeset f2fa4ae74ee1 without any CLI flags at Assertion failure: !tc->inStrictMode()

Definitely a regression, autoBisect is on it.
I also saw this on LangFuzz because one of the jit-tests is failing with that assertion. I minimized that test and got:

eval("'use strict'; @7");
(Reporter)

Comment 2

6 years ago
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   79134:0cff4fe76772
user:        Brendan Eich
date:        Sun Oct 23 22:42:29 2011 -0700
summary:     Ban E4X in ES5 strict mode (bug 695577, r=luke).

This blows up the fuzzers, including decoder's.
Blocks: 695577
(Reporter)

Comment 3

6 years ago
> This blows up the fuzzers, including decoder's.

While this bug is on our ignore list, it will prove really really helpful to have this fixed as it shows up on almost every iteration of fuzzing on debug shells, at least on jsfunfuzz.

Can we have this fixed soon, please? (or at least a patch would be nice?)
(Assignee)

Comment 4

6 years ago
Never really looked into that stuff, but i will take a shot at it.
Assignee: general → evilpies
(Assignee)

Comment 5

6 years ago
Created attachment 572612 [details] [diff] [review]
v1

Maybe this could be done somewhere else, but this fixes it.
Attachment #572612 - Flags: review?(brendan)
(Reporter)

Comment 6

6 years ago
(In reply to Tom Schuster (evilpie) from comment #5)
> Created attachment 572612 [details] [diff] [review] [diff] [details] [review]
> v1
> 
> Maybe this could be done somewhere else, but this fixes it.

This patch seems to hold up fine after 10 minutes of fuzzing, and it prevents the blowing up of fuzzers.
Comment on attachment 572612 [details] [diff] [review]
v1

Thanks.

/be
Attachment #572612 - Flags: review?(brendan) → review+
(Assignee)

Comment 8

6 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/6b839530a88a
Status: NEW → ASSIGNED
Whiteboard: js-triage-needed
https://hg.mozilla.org/mozilla-central/rev/6b839530a88a
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
(Reporter)

Comment 10

5 years ago
Nominating for esr10 probably after 10.0.3, this will be nice to have for fuzzing on that branch.

Without the patch a lot of noise is generated - even though we could ignore this assert, due to the simple nature of the testcase, this may mask other asserts.

There have not been regressions on other branches since this patch landed some months ago.
tracking-firefox-esr10: --- → ?

Updated

5 years ago
tracking-firefox-esr10: ? → 12+
Attachment #572612 - Flags: approval-mozilla-esr10?
Comment on attachment 572612 [details] [diff] [review]
v1

[Triage Comment]
Please go ahead and land, see https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for details.
Attachment #572612 - Flags: approval-mozilla-esr10? → approval-mozilla-esr10+
(Reporter)

Comment 12

5 years ago
Landed on esr10:

http://hg.mozilla.org/releases/mozilla-esr10/rev/27b1269dac4d
status-firefox-esr10: --- → fixed
Whiteboard: [qa+]
Verified fixed in Firefox 10.0.5esrpre 2012-05-31 js-shell.
status-firefox-esr10: fixed → verified
Whiteboard: [qa+] → [qa+:ashughes]
You need to log in before you can comment on or make changes to this bug.