Assertion failure: !val.isMagic(), at jsobj.cpp:5358

VERIFIED FIXED in Firefox 29

Status

()

--
critical
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: decoder, Assigned: bhackett)

Tracking

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

Trunk
mozilla29
x86
Linux
assertion, testcase
Points:
---

Firefox Tracking Flags

(firefox27 wontfix, firefox28 wontfix, firefox29 verified)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
The following testcase asserts on mozilla-central revision bc8c1eb0f2ba (run with --fuzzing-safe):


function test() {
  eval("with (arguments) var arguments = 0;");
} test();
(Reporter)

Comment 1

5 years ago
Created attachment 830136 [details]
[crash-signature] Machine-readable crash signature
Direct eval correctly marks the enclosing function 'test' as requiring an arguments object.

The 'arguments; setaliased; pop' bytecode sequence is emitted in the prolog as expected.

However, at runtime, when we execute that bytecode, we nonetheless store MagicValue(JS_OPTIMIZED_ARGUMENTS) in the Call object, I think because of this in ScriptAnalysis::needsArgsObj():

    /*
     ...
     * New accesses on 'arguments' can occur through 'eval' or the debugger
     * statement. In the former case, we will dynamically detect the use and
     * mark the arguments optimization as having failed.
     */
    if (script_->bindingsAccessedDynamically)
        return false;

The comment there seems all right. But then we get into the eval code and the magic value is still there.  The direct eval code is sensible:

  00000:  defvar "arguments"
  main:
  00005:  name "arguments"
  00010:  enterwith
  ...

During JSOP_NAME, with the stack
  Interpret -> NameOperation -> FetchNameNoGC
we fetch MagicValue(JS_OPTIMIZED_ARGUMENTS) out of slot 2 of the Call object.

During JSOP_ENTERWITH, we assert. Somewhere we should have been able to "dynamically detect the use", but we didn't.

Comment 3

5 years ago
I think the deoptimization is supposed to happen when compiling the eval, when 'arguments' is encountered.  IIRC, this was part of the optimization in bug 842522.
Yeah, bug 842522 introduced it. Brian, can you take this?
Flags: needinfo?(bhackett1024)
(Assignee)

Comment 5

5 years ago
Created attachment 8348332 [details] [diff] [review]
patch

We try to check for 'arguments' within an eval script by looking at its free variables.  Unfortunately, free variables aren't computed correctly for |with| statements and we need to do a stupid workaround.  That workaround didn't work when the |with| was within the eval itself (only when the with was within the function itself, where we hit the same issues).
Assignee: general → bhackett1024
Attachment #8348332 - Flags: review?(luke)
Flags: needinfo?(bhackett1024)

Updated

5 years ago
Attachment #8348332 - Flags: review?(luke) → review+
https://hg.mozilla.org/mozilla-central/rev/6a8bcdd35d1e
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29

Updated

5 years ago
Duplicate of this bug: 896419
(Reporter)

Updated

5 years ago
status-firefox27: --- → affected
status-firefox28: --- → affected
(Reporter)

Comment 9

5 years ago
Created attachment 8351449 [details]
[crash-signature] Machine-readable crash signature
Attachment #830136 - Attachment is obsolete: true

Updated

5 years ago
Duplicate of this bug: 956308

Updated

5 years ago
Keywords: verifyme
(Reporter)

Updated

5 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 11

5 years ago
JSBugMon: This bug has been automatically verified fixed.

Updated

5 years ago
Keywords: verifyme
status-firefox27: affected → wontfix
status-firefox28: affected → wontfix
status-firefox29: --- → verified
You need to log in before you can comment on or make changes to this bug.