Last Comment Bug 613452 - "Assertion failure: obj->isExtensible()" with Object.seal, sharps
: "Assertion failure: obj->isExtensible()" with Object.seal, sharps
: assertion, regression, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All Linux
-- critical (vote)
: mozilla8
Assigned To: Jason Orendorff [:jorendorff]
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: jsfunfuzz 492845
  Show dependency treegraph
Reported: 2010-11-19 01:05 PST by Jesse Ruderman
Modified: 2011-08-12 08:11 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

stack trace (2.25 KB, text/plain)
2010-11-19 01:05 PST, Jesse Ruderman
no flags Details
v1 (2.81 KB, patch)
2011-03-03 13:36 PST, Jason Orendorff [:jorendorff]
jwalden+bmo: review+
Details | Diff | Splinter Review

Description User image Jesse Ruderman 2010-11-19 01:05:03 PST
Created attachment 491791 [details]
stack trace

js> (#1={x:Object.seal(#1#)})

Debug asserts:
Assertion failure: obj->isExtensible(), at jspropertycacheinlines.h:133

Opt behavior seems reasonable:
typein:1: TypeError: ({}) is not extensible

The first bad revision is:
changeset:   441f83a81fb8
user:        Jim Blandy
date:        Tue Sep 21 11:35:30 2010 -0700
summary:     Bug 492845: Implement Object.isSealed, Object.seal. a=jwalden, r=brendan
Comment 1 User image Gary Kwong [:gkw] [:nth10sd] 2011-01-18 20:18:09 PST
Still occurs as of TM changeset 284811f39ca6 on a 32-bit shell on Linux.

(gdb) bt
#0  0xf7fdf430 in __kernel_vsyscall ()
#1  0xf7fb7610 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
#2  0x081cbae1 in JS_Assert (s=0x83b9534 "obj->isExtensible()", file=0x83b944c "/home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/jspropertycacheinlines.h", ln=133)
    at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/jsutil.cpp:83
#3  0x08325e9d in js::PropertyCache::testForInit (this=0x840387c, rt=0x84035e8, pc=0x848f0a9 "]", obj=0xf7608048, shapep=0xffffc948, entryp=0xffffc940)
    at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/jspropertycacheinlines.h:133
#4  0x0831e106 in js::Interpret (cx=0x8451e78, entryFrame=0xf7790030, inlineCallCount=0, interpMode=JSINTERP_NORMAL)
    at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/jsinterp.cpp:5955
#5  0x0810731c in js::RunScript (cx=0x8451e78, script=0x848f020, fp=0xf7790030) at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/jsinterp.cpp:657
#6  0x08108597 in js::Execute (cx=0x8451e78, chain=0xf7602028, script=0x848f020, prev=0x0, flags=0, result=0xffffd210)
    at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/jsinterp.cpp:1023
#7  0x08074871 in JS_ExecuteScript (cx=0x8451e78, obj=0xf7602028, script=0x848f020, rval=0xffffd210) at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/jsapi.cpp:4883
#8  0x0804c78b in Process (cx=0x8451e78, obj=0xf7602028, filename=0x0, forceTTY=0) at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/shell/js.cpp:548
#9  0x0804d3e5 in ProcessArgs (cx=0x8451e78, obj=0xf7602028, argv=0xffffd418, argc=0) at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/shell/js.cpp:943
#10 0x08056c86 in Shell (cx=0x8451e78, argc=0, argv=0xffffd418, envp=0xffffd41c) at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/shell/js.cpp:5428
#11 0x08056e61 in main (argc=0, argv=0xffffd418, envp=0xffffd41c) at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-60455-284811f39ca6/compilePath/shell/js.cpp:5536
Comment 2 User image Jason Orendorff [:jorendorff] 2011-03-03 13:36:52 PST
Created attachment 516691 [details] [diff] [review]

The assertion is invalid in the face of sharp variables exposing an object to script ahead of a JSOP_INITPROP on that object.

This moves the assertion someplace safe. I'll try to remember to move it back once sharp variables are removed.

(JSOP_INITPROP/JSOP_INITMETHOD only make a property cache entry if a property is actually added. If the object is inextensible, that can't happen, so the property cache contains no entries for INIT opcodes on inextensible objects.)
Comment 3 User image Jason Orendorff [:jorendorff] 2011-08-11 11:26:37 PDT
Comment 4 User image Matt Brubeck (:mbrubeck) 2011-08-12 08:11:51 PDT

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