1157566 - Assertion failure: self->contains(cx, aprop), at js/src/vm/Shape.cpp with setObjectMetadataCallback

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

// Combination of:
// jsfunfuzz-generated
// js/src/jit-test/tests/ion/bug1054241.js
// js/src/jit-test/tests/jaeger/globalOptimize-2.js
evalcx("setObjectMetadataCallback(1);Array;x = 0;delete x;", newGlobal());

asserts js debug shell on m-c changeset a5af73b32ac8 with --fuzzing-safe --no-threads --ion-eager at Assertion failure: self->contains(cx, aprop), at js/src/vm/Shape.cpp.

Configure options:

CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213 sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-debug --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

python -u ~/fuzzing/js/compileShell.py -b "--enable-debug --enable-more-deterministic --enable-nspr-build" -r a5af73b32ac8

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/fb294a66c8ac
user:        Nicolas B. Pierron
date:        Wed Aug 20 20:41:26 2014 +0200
summary:     Bug 1054241 - Use AutoEnterAnalysis to avoid iterating the stack under RNewArray allocations. r=bhackett

Nicolas, is bug 1054241 a likely regressor?

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: stack

(lldb) bt 5
* thread #1: tid = 0xa9daa, 0x0000000100265cbb js-dbg-64-dm-nsprBuild-darwin-a5af73b32ac8`js::NativeObject::removeProperty(this=<unavailable>, cx=<unavailable>, id_=<unavailable>) + 1515 at Shape.cpp:985, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000100265cbb js-dbg-64-dm-nsprBuild-darwin-a5af73b32ac8`js::NativeObject::removeProperty(this=<unavailable>, cx=<unavailable>, id_=<unavailable>) + 1515 at Shape.cpp:985
    frame #1: 0x000000010026cda9 js-dbg-64-dm-nsprBuild-darwin-a5af73b32ac8`js::NativeDeleteProperty(cx=0x0000000101ea5180, obj=<unavailable>, id=<unavailable>, result=<unavailable>) + 761 at NativeObject.cpp:2347
    frame #2: 0x0000000100708247 js-dbg-64-dm-nsprBuild-darwin-a5af73b32ac8`js::DeleteProperty(cx=<unavailable>, obj=<unavailable>, id=<unavailable>, result=<unavailable>) + 247 at jsobjinlines.h:190
    frame #3: 0x000000010020277c js-dbg-64-dm-nsprBuild-darwin-a5af73b32ac8`js::DeleteNameOperation(cx=0x0000000101ea5180, name=<unavailable>, scopeObj=<unavailable>, res=<unavailable>) + 652 at Interpreter.cpp:4481
    frame #4: 0x0000000101bd0ab3
(lldb)

Comment 2

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision a38c23ccca0a).

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

This still reproduces for me with m-c rev ffa83d153080.

Comment 4

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 7649ffe28b67).

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

evalcx("enableShellObjectMetadataCallback(1);Array;x = 0;delete x;", newGlobal());


still asserts js debug shell on m-c changeset 7649ffe28b67 with --fuzzing-safe --no-threads --ion-eager at Assertion failure: self->contains(cx, aprop), at vm/Shape.cpp

The following changeset had changed setObjectMetadataCallback to enableShellObjectMetadataCallback:

https://hg.mozilla.org/mozilla-central/rev/2d5da0d1ed25

(note that the commit message has an incorrect name for enableShellObjectMetadataCallback - it had been specified as "enableObjectMetadataCallback")

Comment 6

[Nicolas B. Pierron [:nbp]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #0)
> The first bad revision is:
> changeset:   https://hg.mozilla.org/mozilla-central/rev/fb294a66c8ac
> 
> Nicolas, is bug 1054241 a likely regressor?

Sorry for the late reply.
Certainly not.

I managed to reproduce this issue with --no-threads --no-baseline --no-ion --fuzzing-safe with the test case in comment 5.  Testing with --no-threads --no-baseline --no-ion, I managed to reduce the test case to:

  evalcx("enableShellObjectMetadataCallback(1);Array", newGlobal());

which leads to the following assertion:

  Assertion failure: !entry->shape(), at …/vm/Shape.cpp:554

My guess is the following: While we create the constructor for the Array, we call the ShellObjectMetadataCallback functions which happen to be creating and attaching the Array property on the global.  Thus the entry for $jsid("Array") on the global already has a shape, which trigger the assertion we see above.


Breakpoint 4, ShellObjectMetadataCallback (cx=0x13c5210)
(gdb) bt
#0  ShellObjectMetadataCallback (cx=0x13c5210) at TestingFunctions.cpp:1509
#1  0x00000000009bb444 in JSCompartment::setNewObjectMetadata (this=0x1589b20, cx=0x13c5210, obj=(JSObject *) 0x7ffff7e890c0 [object Array] delegate) at jscompartment.cpp:893
#2  0x00000000009b44eb in js::SetNewObjectMetadata (cxArg=0x13c5210, obj=(JSObject *) 0x7ffff7e890c0 [object Array] delegate) at jsobjinlines.h:294
#3  0x00000000009bc371 in js::AutoSetNewObjectMetadata::~AutoSetNewObjectMetadata (this=0x7fffffff43b0, __in_chrg=<optimized out>) at jscompartment.cpp:1175
#4  0x00000000005393d1 in CreateArrayPrototype (cx=0x13c5210, key=JSProto_Array) at /home/nicolas/mozilla/wksp-4-dev/js/src/jsarray.cpp:3244
#5  0x0000000000b785a1 in js::GlobalObject::resolveConstructor (cx=0x13c5210, global=(js::GlobalObject * const) 0x7ffff7e85060 [object global] delegate, key=JSProto_Array) at vm/GlobalObject.cpp:158


Breakpoint 4, ShellObjectMetadataCallback (cx=0x13c5210)
(gdb) bt
#0  ShellObjectMetadataCallback (cx=0x13c5210) at TestingFunctions.cpp:1509
#1  0x00000000009bb444 in JSCompartment::setNewObjectMetadata (this=0x1589b20, cx=0x13c5210, obj=(JSObject *) 0x7ffff7ea51c0 [object Function <unnamed>]) at jscompartment.cpp:893
#2  0x00000000009ee89c in js::SetNewObjectMetadata (cxArg=0x13c5210, obj=(JSObject *) 0x7ffff7ea51c0 [object Function <unnamed>]) at jsobjinlines.h:294
#3  0x0000000000a3836e in JSObject::create (cx=0x13c5210, kind=js::gc::AllocKind::FIRST, heap=js::gc::TenuredHeap, shape=0x7ffff7e84268, group=0x7ffff7e82250) at jsobjinlines.h:360
#4  0x0000000000a1bedf in NewObject (cx=0x13c5210, group=0x7ffff7e82250, kind=js::gc::AllocKind::FIRST, newKind=js::SingletonObject, initialShapeFlags=0) at jsobj.cpp:685
#5  0x0000000000a1c805 in js::NewObjectWithClassProtoCommon (cxArg=0x13c5210, clasp=0x137a7a0 <JSFunction::class_>, protoArg=0x0, allocKind=js::gc::AllocKind::FIRST, newKind=js::SingletonObject) at jsobj.cpp:813
#6  0x00000000005d105c in js::NewObjectWithClassProto (cx=0x13c5210, clasp=0x137a7a0 <JSFunction::class_>, proto=0x0, allocKind=js::gc::AllocKind::FIRST, newKind=js::SingletonObject) at jsobjinlines.h:679
#7  0x00000000009f79a9 in js::NewFunctionWithProto (cx=0x13c5210, native=0x538cf6 <js::ArrayConstructor(JSContext*, unsigned int, JS::Value*)>, nargs=1, flags=JSFunction::CONSTRUCTOR, enclosingDynamicScope=0x0, atom="Array", proto=0x0, allocKind=js::gc::AllocKind::FIRST, newKind=js::SingletonObject) at jsfun.cpp:2028
#8  0x00000000009f7633 in js::NewNativeConstructor (cx=0x13c5210, native=0x538cf6 <js::ArrayConstructor(JSContext*, unsigned int, JS::Value*)>, nargs=1, atom="Array", allocKind=js::gc::AllocKind::FIRST, newKind=js::GenericObject, flags=JSFunction::CONSTRUCTOR) at jsfun.cpp:1979
#9  0x0000000000b7a062 in js::GlobalObject::createConstructor (this=(js::GlobalObject * const) 0x7ffff7e85060 [object global] delegate, cx=0x13c5210, ctor=0x538cf6 <js::ArrayConstructor(JSContext*, unsigned int, JS::Value*)>, nameArg="Array", length=1, kind=js::gc::AllocKind::FIRST, jitInfo=0xf60130 <js::jit::JitInfo_Array>) at vm/GlobalObject.cpp:466
#10 0x0000000000559856 in js::GenericCreateConstructor<&js::ArrayConstructor, 1u, (js::gc::AllocKind)0, &js::jit::JitInfo_Array> (cx=0x13c5210, key=JSProto_Array) at vm/GlobalObject.h:925
#11 0x0000000000b78655 in js::GlobalObject::resolveConstructor (cx=0x13c5210, global=(js::GlobalObject * const) 0x7ffff7e85060 [object global] delegate, key=JSProto_Array) at/home/nicolas/mozilla/wksp-4-dev/js/src/vm/GlobalObject.cpp:166


Program received signal SIGSEGV, Segmentation fault.
554                 MOZ_ASSERT(!entry->shape());
(gdb) bt
#0  0x0000000000c59a1c in js::NativeObject::addPropertyInternal (cx=0x13c5210, obj=(js::NativeObject * const) 0x7ffff7e85060 [object global] delegate, id=$jsid("Array"), getter=0x0, setter=0x0, slot=124, attrs=0, flags=0, entry=0x15a7610, allowDictionary=true) at vm/Shape.cpp:554
#1  0x0000000000c595d0 in js::NativeObject::addProperty (cx=0x13c5210, obj=(js::NativeObject * const) 0x7ffff7e85060 [object global] delegate, id=$jsid("Array"), getter=0x0, setter=0x0, slot=124, attrs=0, flags=0, allowDictionary=true) at vm/Shape.cpp:499
#2  0x0000000000bef6e4 in js::NativeObject::addDataProperty (this=(js::NativeObject * const) 0x7ffff7e85060 [object global] delegate, cx=0x13c5210, idArg=$jsid("Array"), slot=124, attrs=0) at vm/NativeObject.cpp:953
#3  0x0000000000b78767 in js::GlobalObject::resolveConstructor (cx=0x13c5210, global=(js::GlobalObject * const) 0x7ffff7e85060 [object global] delegate, key=JSProto_Array) at vm/GlobalObject.cpp:172

Comment 7

[Shu-yu Guo [:shu]]

I don't reproduce with the testcase Nicolas put in comment 6. What build of m-c does this reproduce on?

Comment 8

[Nicolas B. Pierron [:nbp]]

(In reply to Shu-yu Guo [:shu] from comment #7)
> I don't reproduce with the testcase Nicolas put in comment 6. What build of
> m-c does this reproduce on?

I reproduced it with both debug/optimized builds on x64.
I build with a disabled Intl library, which might change the number of variables attached on the global which might cause the cliff effect on 192 (256 - 256 >> 2) pass by sooner in js::NativeObject::addPropertyInternal

I configure with:

  --enable-valgrind --disable-jemalloc --enable-threadsafe --with-system-nspr --with-nspr-prefix=…/_inst/nsprpub/master/x64/gcc48/dbg --disable-intl-api --without-intl-api --enable-debug=-ggdb3 --enable-debug-symbols --disable-elf-hack --disable-optimize --enable-profiling --enable-ctypes --enable-warnings-as-errors

And ran with: --no-threads --no-baseline --no-ion (without fuzzing-safe option, otherwise it does not reproduce)

Comment 9

[Nicolas B. Pierron [:nbp]]

(In reply to Shu-yu Guo [:shu] from comment #7)
> I don't reproduce with the testcase Nicolas put in comment 6. What build of
> m-c does this reproduce on?

I do not have the changeset of it (for some reason that I don't know) but the git sha1 of gecko-dev is b4d42f3, which is m-c from 2 days ago.

Comment 10

[Shu-yu Guo [:shu]]

Okay, I reproduced and Nicolas's guess in comment 6 is correct. When resolving the Array constructor, creating the Array prototype ends up calling the shell object metadata callback. The shell object metadata callback creates a NewDenseEmptyArray, which now re-enters resolving the Array constructor. When the callback finishes, we return to the outer resolve call and hit the assert.

Not sure how to fix yet, don't remember how this callback works.

Comment 11

[Christian Holler (:decoder)]

According to the signature, this might well be a duplicate of bug 1064058.

Comment 13

[Fuzzing Team]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision eb25b90a05c1).

Comment 14

[Fuzzing Team]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision c59c022943f6).
JSBugMon: Fix Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "bad" changeset has the timestamp "20160222150752" and the hash "2bf13f9218ad117b54636a2a878ad9464d33f7e3".
The "good" changeset has the timestamp "20160222151850" and the hash "e6abb35f9fb9339241aca3a8ec255b16636d80d7".

Likely fix window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2bf13f9218ad117b54636a2a878ad9464d33f7e3&tochange=e6abb35f9fb9339241aca3a8ec255b16636d80d7

Comment 15

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Jim, is bug 1221378 or bug 1247126 a likely fix?

Comment 16

[Jim Blandy :jimb]

That's bug 1221378, almost certainly.

Comment 17

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Resolving FIXED by bug 1221378, thanks!