1124563 - Assertion failure: obj->lastProperty() == p->value().shape, at jsinfer.cpp

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

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

try {
    gc(0, 'shrinking')({x: 0})
} catch (e) {}
eval("({x: 0, x: 0})[{x: 0}]")

asserts js debug shell on m-c changeset 34e2d2bd7ec4 with --fuzzing-safe --no-threads --no-ion at Assertion failure: obj->lastProperty() == p->value().shape, at jsinfer.cpp

Debug 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-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

=== Tinderbox Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20150121001427" and the hash "1533b263c457".
The "bad" changeset has the timestamp "20150121013236" and the hash "26d8f946a53b".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1533b263c457&tochange=26d8f946a53b

Setting this s-s first since compacting GC seems to be involved.

Jon, is bug 650161 aka compacting GC a likely regressor, or is it exposing the issue?

Comment 1

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

Attachment: stack

(lldb) bt 5
* thread #1: tid = 0x23cec, 0x000000010060ceb7 js-dbg-opt-64-dm-nsprBuild-darwin-7148aa99ad67`js::types::TypeCompartment::fixObjectType(this=<unavailable>, cx=<unavailable>, obj=<unavailable>) + 3175 at jsinfer.cpp:2829, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010060ceb7 js-dbg-opt-64-dm-nsprBuild-darwin-7148aa99ad67`js::types::TypeCompartment::fixObjectType(this=<unavailable>, cx=<unavailable>, obj=<unavailable>) + 3175 at jsinfer.cpp:2829
    frame #1: 0x000000010017c876 js-dbg-opt-64-dm-nsprBuild-darwin-7148aa99ad67`js::frontend::ParseNode::getConstantValue(js::ExclusiveContext*, js::frontend::ParseNode::AllowConstantObjects, JS::MutableHandle<JS::Value>) [inlined] js::types::FixObjectType(obj=0x00000001041850a0) + 2086 at jsinferinlines.h:568
    frame #2: 0x000000010017c82e js-dbg-opt-64-dm-nsprBuild-darwin-7148aa99ad67`js::frontend::ParseNode::getConstantValue(this=<unavailable>, cx=<unavailable>, allowObjects=<unavailable>, vp=<unavailable>) + 2014 at BytecodeEmitter.cpp:4363
    frame #3: 0x0000000100183b37 js-dbg-opt-64-dm-nsprBuild-darwin-7148aa99ad67`EmitSingletonInitialiser(cx=0x0000000101e02260, bce=0x00007fff5fbfcde0, pn=<unavailable>) + 87 at BytecodeEmitter.cpp:4377
    frame #4: 0x0000000100184d3c js-dbg-opt-64-dm-nsprBuild-darwin-7148aa99ad67`EmitObject(cx=0x0000000101e02260, bce=0x00007fff5fbfcde0, pn=0x000000010281cfa8) + 2028 at BytecodeEmitter.cpp:6582
(lldb)

Comment 2

[Jon Coppeard (:jonco)]

The problem is that we aren't fixing up the baseShapes hash table, whose keys are based on objects that can be moved by GC.

Comment 4

[Jon Coppeard (:jonco)]

Attachment: bug1124563-fixup-base-shapes-table

This patch fixes the particular problem of the table not being updated on compacting GC.

Unfortunately this is still a problem for generational GC.

Comment 5

[Jon Coppeard (:jonco)]

I'm going to land this patch now and fix the generational issue in bug 1127246.

Comment 6

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/da03ea6e22dd

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/da03ea6e22dd

Comment 8

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 9

[Jon Coppeard (:jonco)]

Attachment: bug1124563-aurora

This is a dependency for bug 1127246.

Approval Request Comment
[Feature/regressing bug #]: Bug 650161.
[User impact if declined]: Possible stability/security issue due to bug 1127246.
[Describe test coverage new/current, TreeHerder]: On m-c for 5 days.
[Risks and why]: Low.
[String/UUID change made/needed]: None.

Comment 10

[Jon Coppeard (:jonco)]

Attachment: bug1124563-beta

This is a dependency for bug 1127246.

Approval Request Comment
[Feature/regressing bug #]: Bug 650161.
[User impact if declined]: Possible stability/security issue due to bug 1127246.
[Describe test coverage new/current, TreeHerder]: On m-c for 5 days.
[Risks and why]: Low.
[String/UUID change made/needed]: None.

Comment 11

[Jon Coppeard (:jonco)]

BTW the uplift patches for aurora and beta are to fix 'ggc' test build errors, and mainly touch code that's #ifdefed out in the main builds.

Comment 12

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/afb266213a03

Comment 13

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/releases/mozilla-beta/rev/5eae334a2b31

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/afb266213a03

Comment 15

[Al Billings [:abillings - ex-MoCo]]

If bug 650161 is the regressor, how did this affect 36? Looking at checkin dates, bug 650161 appears to be either 37 or 38 only.

Comment 16

[Jon Coppeard (:jonco)]

(In reply to Al Billings [:abillings] from comment #15)
The code in bug 650161 is only built by default in 38 onwards, however the code is present in earlier versions and the 'ggc' test build does build and test this.

The uplift was done so that that this test will pass and doesn't affect the normal builds for 36 and 37.

Comment 17

[Al Billings [:abillings - ex-MoCo]]

Ah, thanks. Minusing it for advisories for 36 then.