622041 - Assertion failure: fun->isFlatClosure() or null-pointer crash [@ JS_GetAnonymousString]

Status: RESOLVED DUPLICATE of bug 592202

(Core :: JavaScript Engine, defect)

Description

[Alex Miller]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: 

While it is only a null pointer dereference crash, further investigation shows that various parameters on the stack are 0xFEEEFEEE, which is the pattern left behind by Microsoft's HeapFree() function. Also, memory is executed at 0xFFFF0001, which seems a bit scary.

Testcase: 
x2 = 1;
eval("let(x, x3 = 1e4.__proto__) ((function(){let(x1 = x) ((function(){(x) = x2;})());})());");

(I ran this on the tracemonkey repo)

Reproducible: Always

Comment 1

[Alex Miller]

Attachment: Really screwed up stack trace

That is the weirdest stack trace I've ever seen.

Comment 2

[Alex Miller]

Attachment: Correcting the above testcase

Comment 3

[Alex Miller]

Also, the stacktrace from this crash with -j and -m makes a little more sense in that the previous frames were JS-related. However, regardless of any JITs in use, there is still a call to 0xFFFF0001 and one parameter is 0xFEEEFEEE.

Comment 4

[Alex Miller]

I think this is purely a semantic issue, but now the assertion I am getting is Assertion failure: fun->isFlatClosure()

Comment 5

[Alex Miller]

I think this is purely a semantic issue, but now the assertion I am getting is Assertion failure: fun->isFlatClosure(), but the null pointer deref crash is still at the same place.

Comment 6

[Jeff Walden [:Waldo]]

Yeah, I rejiggered this code a little and changed the assertion slightly -- it happens.

Comment 7

[Alex Miller]

On a linux opt build this crashes the same way bug 592202 does. ([@js::SetFlatUpvar])