Bug 119830 - Assigning to a readonly global results in DFG byte code parse failure
Summary: Assigning to a readonly global results in DFG byte code parse failure
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Oliver Hunt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-14 17:57 PDT by Oliver Hunt
Modified: 2013-08-15 14:51 PDT (History)
2 users (show)

See Also:


Attachments
Patch (5.46 KB, patch)
2013-08-15 12:39 PDT, Oliver Hunt
fpizlo: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Hunt 2013-08-14 17:57:52 PDT
JSC fails to compile

for (;;) { try { eval("NaN = 0"); } catch(e) {} }

Due to a parse failure of Dynamic put
Comment 1 Oliver Hunt 2013-08-15 12:39:00 PDT
Created attachment 208838 [details]
Patch
Comment 2 Filip Pizlo 2013-08-15 12:41:07 PDT
Comment on attachment 208838 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=208838&action=review

> Source/JavaScriptCore/dfg/DFGCapabilities.cpp:178
> +        // If we're writing to a readonly property we emit a Dynamic put that
> +        // the DFG can't currently handle.

Really?
Comment 3 Filip Pizlo 2013-08-15 12:41:43 PDT
Comment on attachment 208838 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=208838&action=review

>> Source/JavaScriptCore/dfg/DFGCapabilities.cpp:178
>> +        // the DFG can't currently handle.
> 
> Really?

Oh, yeah, really.
Comment 4 Oliver Hunt 2013-08-15 12:43:11 PDT
Committed r154120: <http://trac.webkit.org/changeset/154120>
Comment 5 Filip Pizlo 2013-08-15 14:51:34 PDT
Comment on attachment 208838 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=208838&action=review

> Source/JavaScriptCore/dfg/DFGCapabilities.cpp:186
> -        ResolveType resolveType = static_cast<ResolveType>(pc[3].u.operand);
> +        ResolveType resolveType = ResolveModeAndType(pc[4].u.operand).type();

Why?  It appears that the DFG bytecodeparser and the bytecompiler both put the type in 3, not 4.