Last Comment Bug 698028 - "Assertion failure: !getProto()->inDictionaryMode() || getProto()->lastProp->frozen(), at ../jsobjinlines.h:302" with Debugger eval, lazily creating a Block with 129 variables
: "Assertion failure: !getProto()->inDictionaryMode() || getProto()->lastProp->...
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Other Branch
: x86 Mac OS X
: -- normal (vote)
: mozilla11
Assigned To: Jason Orendorff [:jorendorff]
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: 690558
  Show dependency treegraph
Reported: 2011-10-28 10:25 PDT by Jason Orendorff [:jorendorff]
Modified: 2012-02-01 14:00 PST (History)
1 user (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

v1 (7.20 KB, patch)
2011-10-31 10:42 PDT, Jason Orendorff [:jorendorff]
jimb: review+
Details | Diff | Splinter Review

Description User image Jason Orendorff [:jorendorff] 2011-10-28 10:25:58 PDT
var g = newGlobal('new-compartment');
var dbg = new Debugger(g);
dbg.onDebuggerStatement = function (frame) { frame.eval(''); };
var s = '{ let ';
for (var i = 0; i < 128; i++)
    s += 'x' + i + ', ';
s += 'X = 0; debugger; }';
Comment 1 User image Jason Orendorff [:jorendorff] 2011-10-28 10:58:43 PDT
I had to rewrite this to use evalInFrame() in order to bisect it:

    x00, x01, x02, x03, x04, x05, x06, x07, x08, x09, x0a, x0b, x0c, x0d, x0e, x0f, 
    x10, x11, x12, x13, x14, x15, x16, x17, x18, x19, x1a, x1b, x1c, x1d, x1e, x1f, 
    x20, x21, x22, x23, x24, x25, x26, x27, x28, x29, x2a, x2b, x2c, x2d, x2e, x2f, 
    x30, x31, x32, x33, x34, x35, x36, x37, x38, x39, x3a, x3b, x3c, x3d, x3e, x3f, 
    x40, x41, x42, x43, x44, x45, x46, x47, x48, x49, x4a, x4b, x4c, x4d, x4e, x4f, 
    x50, x51, x52, x53, x54, x55, x56, x57, x58, x59, x5a, x5b, x5c, x5d, x5e, x5f, 
    x60, x61, x62, x63, x64, x65, x66, x67, x68, x69, x6a, x6b, x6c, x6d, x6e, x6f, 
    x70, x71, x72, x73, x74, x75, x76, x77, x78, x79, x7a, x7b, x7c, x7d, x7e, x7f, 
    x80, x81, x82, x83, x84, x85, x86, x87, x88, x89, x8a, x8b, x8c, x8d, x8e, x8f, 
    x90, x91, x92, x93, x94, x95, x96, x97, x98, x99, x9a, x9b, x9c, x9d, x9e, x9f, 
    xa0, xa1, xa2, xa3, xa4, xa5, xa6, xa7, xa8, xa9, xaa, xab, xac, xad, xae, xaf, 
    xb0, xb1, xb2, xb3, xb4, xb5, xb6, xb7, xb8, xb9, xba, xbb, xbc, xbd, xbe, xbf, 
    xc0, xc1, xc2, xc3, xc4, xc5, xc6, xc7, xc8, xc9, xca, xcb, xcc, xcd, xce, xcf, 
    xd0, xd1, xd2, xd3, xd4, xd5, xd6, xd7, xd8, xd9, xda, xdb, xdc, xdd, xde, xdf, 
    xe0, xe1, xe2, xe3, xe4, xe5, xe6, xe7, xe8, xe9, xea, xeb, xec, xed, xee, xef, 
    xf0, xf1, xf2, xf3, xf4, xf5, xf6, xf7, xf8, xf9, xfa, xfb, xfc, xfd, xfe, xff;
  evalInFrame(1, "");

The first bad revision is:
changeset:   64296:67b102d581dd
user:        Jim Blandy <>
date:        Tue Mar 15 12:18:36 2011 -0700
summary:     Bug 554955: Give blocks and call objects unique shapes when they have parents that may be extended with new bindings. r=jorendorff
Comment 2 User image Jason Orendorff [:jorendorff] 2011-10-31 10:42:58 PDT
Created attachment 570757 [details] [diff] [review]

This pokes a hole in the Shape abstraction. I am guessing the eventual answer is to use Bindings for let-bindings too, not just var-bindings. Then PopStatement could just call tc->bindings.makeImmutable().

I'm not sure how much work that will be, so I'm spot-fixing the bug. Regression tests pass.
Comment 3 User image Jason Orendorff [:jorendorff] 2011-11-18 13:55:14 PST
Comment 4 User image Ed Morley [:emorley] 2011-11-19 05:12:30 PST

Note You need to log in before you can comment on or make changes to this bug.