initprop/initelem, sharp variables and duplicated property names

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: Igor Bukanov, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
The bug #522158 removed CheckRedeclaration checks from the interpreter cases for JSOP_INITPROP and JSOP_INITELEM. The assumption was that the compiler should check for the duplicated property names so the bytecodes would always add unique properties to the object.

But this assumption is wrong in presence of sharp variables. They leak the partially initialized object so a script could add a property to the object that matches not yet executed name or index of JSOP_INITPROP and JSOP_INITELEM, like in the following:

function f() {
    return #1={1:(#1#[1] = 2, #1#)};
}

On the surface the bug is very mild as CheckRedeclaration only warns without throwing error (unless throw on warning mode is enabled) in such cases. So one way to fix this bug is to acknowledge the regression and add the comments to refer to this corner cases with sharp variables.

On the other hand our defineProperty implementation that iniprop/initelem call currently does not check for all the restrictions stated ES5 8.12.9 [[DefineOwnProperty]]. In particular, it can change some attributes of non-configurable properties. To prevent this we can change the implementation to set the property, not define it, if it exists.

Yet another possibility would be to fix defineProperty to implement all the restrictions from DefineOwnProperty. But that is not easy, see bug 624364 for reasons.

Comment 1

7 years ago
I'm in favor of a more drastic solution; see bug 633278
Fixed by bug 566700; I'll remove the now-unnecessary checking shortly.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Depends on: 566700
You need to log in before you can comment on or make changes to this bug.