Closed Bug 657193 Opened 9 years ago Closed 8 years ago

TM: Crash [@ js::types::TypeFailure] involving missing type void


(Core :: JavaScript Engine, defect, critical)

Not set





(Reporter: gkw, Unassigned)


(Blocks 3 open bugs)


(Keywords: crash, testcase, Whiteboard: js-triage-needed)

Crash Data

(function() {
    a = {
    } = x, (x._)
    x()( * :: * )

crashes js debug shell on JM changeset ef1ce31f66b9 with -m, -a and -n at js::types::TypeFailure with the following message:

[infer failure] Missing type at #3:00029 pushed 0: void
Bug in TM, there is a JSOP_BINDNAME for the 'x' part of the destructuring initializer which overwrites the local variable even though it is not marked as closed.  This particular case doesn't affect stock JM as QNAMEPART isn't compiled, but there may be similar testcases which do.  Marking as blocking bug 651966, which documents similar issues with DEFVAR and SETCONST.
Depends on: 651966
Duplicate of this bug: 660537
Summary: TI: Crash [@ js::types::TypeFailure] involving missing type void → TM: Crash [@ js::types::TypeFailure] involving missing type void
Chris wanted to take this. Reduced:

function f() {
    var x;
    a = { x } = x

The problem is that the { x } is not being bound to |var x|, so it emits a BINDNAME. JITs and Type Inference require knowing about aliased locals - right now this is noted in JSScript::closedVars,Args (should be renamed aliasedVars,Args).

But for this test, they're not *really* aliased, the parser (or emitter) is just emitting very inefficient bytecode. JM doesn't compile QNAMEPART but if it did this test could crash.
Assignee: general → cdleary
This no longer crashes with the patch in bug 651966, but the emitter weirdness/inefficiency is still there.
Crash Signature: [@ js::types::TypeFailure]
Whiteboard: js-triage-needed
For the testcase in comment #0, I get "TypeError: x is undefined" for interp, -j, -m, and -m -n. No crashes.

Same error message and no crashes for all modes with the testcase in comment #3 either. Brian, is there more to do still per comment #4?
The bytecode is still somewhat inefficient, but behavior is correct.  There are upcoming changes to destructuring parsing that should fix the former issue.
Closed: 8 years ago
Resolution: --- → WORKSFORME
Assignee: cdleary → general
Blocks: 349611
You need to log in before you can comment on or make changes to this bug.