1156190 - Assertion failure: !(IsAboutToBeFinalized(&staticScope_)), at vm/ScopeObject.cpp

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

// Randomly chosen test: js/src/jit-test/tests/debug/Frame-environment-05.js
var g = newGlobal();
var dbg = new Debugger(g);
dbg.onDebuggerStatement = function(frame) {
    frame.onStep = (function() {
        frame.environment;
    });
};
g.eval("debugger; for (let i = 0; i < 99; i++) (function(){});");
// jsfunfuzz-generated
selectforgc(Object);

asserts js debug shell on m-c changeset 50b95032152c with --fuzzing-safe --no-threads --no-baseline --no-ion at Assertion failure: !(IsAboutToBeFinalized(&staticScope_)), at vm/ScopeObject.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 50b95032152c

Comment 1

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

Attachment: stack

(lldb) bt 5
* thread #1: tid = 0xb200b, 0x000000010028f749 js-dbg-64-dm-nsprBuild-darwin-50b95032152c`js::DebugScopes::sweep(JSRuntime*) + 52 at ScopeObject.cpp:1175, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010028f749 js-dbg-64-dm-nsprBuild-darwin-50b95032152c`js::DebugScopes::sweep(JSRuntime*) + 52 at ScopeObject.cpp:1175
    frame #1: 0x000000010028f715 js-dbg-64-dm-nsprBuild-darwin-50b95032152c`js::DebugScopes::sweep(this=<unavailable>, rt=<unavailable>) + 837 at ScopeObject.cpp:1914
    frame #2: 0x00000001007740c3 js-dbg-64-dm-nsprBuild-darwin-50b95032152c`js::gc::GCRuntime::beginSweepingZoneGroup(this=0x0000000101e61348) + 1619 at jsgc.cpp:4876
    frame #3: 0x00000001007756e8 js-dbg-64-dm-nsprBuild-darwin-50b95032152c`js::gc::GCRuntime::beginSweepPhase(this=0x0000000101e61348, destroyingRuntime=<unavailable>) + 1592 at jsgc.cpp:5050
    frame #4: 0x0000000100779422 js-dbg-64-dm-nsprBuild-darwin-50b95032152c`js::gc::GCRuntime::incrementalCollectSlice(this=0x0000000101e61348, budget=0x00007fff5fbff2a8, reason=DESTROY_CONTEXT) + 898 at jsgc.cpp:5803
(lldb)

Comment 2

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

autoBisect is running.

Comment 3

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/731c0cf27a55
user:        Shu-yu Guo
date:        Wed Apr 15 21:55:21 2015 -0700
summary:     Bug 1152304 - Record the end of block scope notes to be after emission of JSOP_POPBLOCKSCOPE. (r=jimb)

Shu-yu, is bug 1152304 a likely regressor?

Comment 4

[Shu-yu Guo [:shu]]

Attachment: Do not emit DEBUGLEAVESCOPE if we're also going to emit POPBLOCKSCOPE.

With bug 1152304, block scope notes were changed such that getBlockScope(pc)
always considers the block at the *beginning* of execution of pc.

Now, when we have block scopes with aliased locals, when exiting the scope we emit

DEBUGLEAVEBLOCK; POPBLOCKSCOPE

in that order.

Since getBlockScope(POPBLOCKSCOPE) now considers the block scope to still be on
the stack, we have the current bug, where

1) DEBUGLEAVEBLOCK removes the current block scope from the
   DebugScopes::liveScopes map.

2) An onStep handler executing before POPBLOCKSCOPE can add that block back to
   DebugScopes::liveScopes, due to the behavior change in bug 1152304.

That liveScope mapping will leak until GC, where we'll assert that it wasn't
properly cleaned up.

Comment 5

[Jim Blandy :jimb]

Comment on attachment 8594983 [details] [diff] [review]
Do not emit DEBUGLEAVESCOPE if we're also going to emit POPBLOCKSCOPE.

Review of attachment 8594983 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jit-test/tests/debug/Environment-gc-03.js
@@ +6,5 @@
> +    frame.onStep = (function() {
> +        frame.environment;
> +    });
> +};
> +g.eval("debugger; for (let i = 0; i < 1; i++) (function(){});");

Could we have an ordinary let block here too?

Don't 'catch' clauses use lexical blocks too?

Comment 6

[Shu-yu Guo [:shu]]

(In reply to Jim Blandy :jimb from comment #5)
> Comment on attachment 8594983 [details] [diff] [review]
> Do not emit DEBUGLEAVESCOPE if we're also going to emit POPBLOCKSCOPE.
> 
> Review of attachment 8594983 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: js/src/jit-test/tests/debug/Environment-gc-03.js
> @@ +6,5 @@
> > +    frame.onStep = (function() {
> > +        frame.environment;
> > +    });
> > +};
> > +g.eval("debugger; for (let i = 0; i < 1; i++) (function(){});");
> 
> Could we have an ordinary let block here too?
> 
> Don't 'catch' clauses use lexical blocks too?

Sure I'll test those.

Comment 7

[Pulsebot]

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

Comment 8

[Ryan VanderMeulen [:RyanVM]]

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