WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 63398
Poisoning of strict caller,arguments inappropriately poisoning "in"
https://bugs.webkit.org/show_bug.cgi?id=63398
Summary
Poisoning of strict caller,arguments inappropriately poisoning "in"
Mark S. Miller
Reported
2011-06-26 06:17:39 PDT
'caller' in function(){"use strict"} TypeError: Cannot access caller property of a strict mode function 'arguments' in function(){"use strict"} TypeError: Can't access arguments object of a strict mode function The poisoning should be equivalent to making 'caller' and 'arguments' into accessor properties whose getter & setter throw. However, getters and setters should not be activated by "in".
Attachments
Demonstrates the ability to catch the TypeError in an outer catch
(39.93 KB, text/plain)
2011-06-26 06:55 PDT
,
Mark S. Miller
no flags
Details
The patch
(6.48 KB, patch)
2011-10-17 18:36 PDT
,
Gavin Barraclough
sam
: review+
Details
Formatted Diff
Diff
experimenting with an alternative way to fix the problem.
(16.69 KB, application/octet-stream)
2011-10-19 14:39 PDT
,
Gavin Barraclough
no flags
Details
Fix
(24.95 KB, patch)
2011-10-19 17:04 PDT
,
Gavin Barraclough
oliver
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Mark S. Miller
Comment 1
2011-06-26 06:42:48 PDT
I'm using WebKit Nightly Version 5.0.5 (5533.21.1,
r89741
). A further weirdness is that the TypeError that's thrown isn't caught by a one level try/catch. try { 'caller' in function(){"use strict"} } catch (e) {} TypeError: Cannot access caller property of a strict mode function Further testing in the context of a larger system (look for "has(" in
http://codereview.appspot.com/4603044/patch/8002/18002?column_width=100
) indicates that there is some two level combination of try/catch/finally which can catch the TypeError in the out catch, even though it had skipped past both the inner catch and finally. However, I haven't isolated this yet into a standalone test case. This may be symptom of a distinct bug. Without one of the finallys there, I also found that testing under the WebKit debigger caused WebKit as a whole to crash. I haven't yet isolated that either.
Mark S. Miller
Comment 2
2011-06-26 06:55:33 PDT
Created
attachment 98621
[details]
Demonstrates the ability to catch the TypeError in an outer catch The attached file demonstrates the ability to catch the TypeError in an outer catch. Look for "has(". This file also contains other diagnostics you may find useful.
Mark S. Miller
Comment 3
2011-08-18 21:08:29 PDT
(function(){"use strict";}).hasOwnProperty('caller') TypeError: Cannot access caller property of a strict mode function The problem also occurs for other operations besides 'in'. Again, as with 'in', the poisoning of 'caller' should not prevent hasOwnProperty from working as specified. hasOwnProperty must not attempt to access the property's value.
Gavin Barraclough
Comment 4
2011-10-17 18:36:12 PDT
Created
attachment 111364
[details]
The patch
Sam Weinig
Comment 5
2011-10-17 18:39:57 PDT
Comment on
attachment 111364
[details]
The patch View in context:
https://bugs.webkit.org/attachment.cgi?id=111364&action=review
> Source/JavaScriptCore/ChangeLog:3 > + Poisoning of strict caller,arguments inappropriately poisoning "in"
The comma here is off.
Gavin Barraclough
Comment 6
2011-10-17 20:43:51 PDT
Fixed in
r97709
. The problem with the exception not being caught was specific to this case of an exception being thrown (we weren't checking for an exception in a case where one never should be thrown), so with the bug fixed there should be no related problem left, but I've added an ASSERT to JIT Stubs that guards against this.
Ryosuke Niwa
Comment 7
2011-10-17 22:12:18 PDT
It appears that a bunch of tests started failing after this patch:
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r97710%20(33977)/results.html
Also, the change long entry was inserted at wrong place.
Gavin Barraclough
Comment 8
2011-10-18 00:52:56 PDT
> Also, the change long entry was inserted at wrong place.
Sorry, svn up keeps doing this to me, I don't always catch it. :-( Rolled out in
r97719
, reopened.
Ryosuke Niwa
Comment 9
2011-10-18 01:06:54 PDT
(In reply to
comment #8
)
> > Also, the change long entry was inserted at wrong place. > Sorry, svn up keeps doing this to me, I don't always catch it. :-(
FYI, webkit-patch land should warn you about this.
Gavin Barraclough
Comment 10
2011-10-19 14:39:06 PDT
Created
attachment 111677
[details]
experimenting with an alternative way to fix the problem.
Gavin Barraclough
Comment 11
2011-10-19 17:04:32 PDT
Created
attachment 111698
[details]
Fix
Gavin Barraclough
Comment 12
2011-10-19 18:18:27 PDT
Resolved in
r97905
.
Gavin Barraclough
Comment 13
2012-03-26 13:20:06 PDT
***
Bug 56492
has been marked as a duplicate of this bug. ***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug