"window.__proto__ = window" doesn't throw, again

RESOLVED FIXED

Status

()

RESOLVED FIXED
6 years ago
8 months ago

People

(Reporter: jruderman, Assigned: Waldo)

Tracking

(Blocks: 1 bug, {regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 671631 [details]
testcase

Expected: Line 4 should throw "TypeError: cyclic __proto__ value"
Result:   Line 5 throws "too much recursion"

Blake fixed this once, in bug 394815...
(Assignee)

Comment 1

6 years ago
...and we didn't push a testcase.  Good times.

Looking at this in a debugger, inside the __proto__ setter implementation |this| is a Window object, but the argument passed in is a Proxy (presumably around that Window).  At first pale I think this suggests the JS __proto__ setter needs to do more work here, but I'm not sure enough of that diagnosis to change the component yet.  I'll look and figure it out.
Assignee: nobody → jwalden+bmo
OS: Mac OS X → All
Hardware: x86_64 → All
(Assignee)

Comment 2

6 years ago
Likely-looking shell testcase:

  var obj = {}; obj.__proto__ = wrap(obj);

That appears to have been failing for awhile, as the change before bug 770344 (making __proto__ an accessor, mid-July this year) reports infinite recursion on it.  Poking people now to see if the regressing bug can be determined...
Note to self:
~/fuzzing/autobisect-js/autoBisect.py -p "-e obj={};obj.__proto__=wrap(obj);obj.toString" -i outputs --timeout=3 "InternalError: too much recursion"


autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   59231:f2938738a9b1
user:        Andreas Gal
date:        Mon Dec 13 14:53:44 2010 -0800
summary:     Check for infinite recursion when running proxy handlers (bug 571168, r=jorendorff).

It crashed at the parent changeset. I'm now verifying that the latest non-crashing changeset before f2938738a9b1 hopefully shows the cyclic message.
The last non-crashing changeset, 49da92b4c672, which before f2938738a9b1, shows:

./js-dbg-64-49da92b4c672-linux -e "obj={};obj.__proto__=wrap(obj);obj.toString"
-e:1: ReferenceError: wrap is not defined

As for the crash in comment 3,

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   42733:4dd9be00049c
user:        Andreas Gal
date:        Tue May 18 19:21:43 2010 -0700
summary:     Implement ES Harmony Proxies (bug 546590, r=mrbkap).

===

In summary:

49da92b4c672 shows "ReferenceError: wrap is not defined"
4dd9be00049c, child of 49da92b4c672, and onwards crashes, until...
f2938738a9b1 fixed the crash but shows "InternalError: too much recursion".

Hope this helps.
(Assignee)

Comment 5

6 years ago
Hmm.  Yes, and no.  Basically it appears this was broken somewhere back in the sands of time, far enough back that regression info probably won't help with a fix.  But at least we know that now!
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #1)
> ...and we didn't push a testcase.  Good times.

I'm going to defend myself: there definitely was a testcase at some point (I think I've fixed this bug at least 3 or 4 times since the implementation of XOWs). I bet it got lost when we did the compartments work.

Comment 7

8 months ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → INACTIVE
So for window this now throws because windows have immutable protos.

For other cases... I think this is all fine now, as far as I can tell.
Resolution: INACTIVE → FIXED
Duplicate of this bug: 617516
You need to log in before you can comment on or make changes to this bug.