1024492 - Assertion failure: isScripted(), at js/src/jit/IonFrames.cpp:184

Status: RESOLVED DUPLICATE of bug 1006077

(Core :: JavaScript Engine, defect)

Description

[André Bargull [:anba]]

Steps to reproduce:
1. Execute: `load("/tmp/assert.js"); runTest(0xfff);`

Note: I wasn't able to reproduce the error in an unoptimized debug build, 

File "assert.js":
---
function runTest(iter) {

var stringFilter = {

movies: [ "The Shawshank Redemption (1994)" ],

run: function() {

var results = new Array();
var needle = /.*star.*/i;
for (var k = 0; k < this.movies.length; k++) {

}

}

}

var niter = (iter||0xff)|0;
var start = Date.now();
for (var i=0;i<niter;++i) {
  stringFilter.run();
}
return Date.now() - start
}
---

Stack trace:
---
#0  0x00000000005e2688 in js::jit::JitFrameIterator::script (this=<optimized out>)
    at /home/andre/git/mozilla-central-master/js/src/jit/IonFrames.cpp:184
#1  0x000000000055f839 in js::jit::BailoutIonToBaseline (cx=cx@entry=0x2bd95b0, activation=activation@entry=0x7fff39a57d10, iter=..., 
    invalidate=invalidate@entry=true, bailoutInfo=bailoutInfo@entry=0x7fff39a57b00, excInfo=0x1, excInfo@entry=0x0)
    at /home/andre/git/mozilla-central-master/js/src/jit/BaselineBailouts.cpp:1336
#2  0x000000000056016b in js::jit::InvalidationBailout (sp=0x7fff39a57b10, frameSizeOut=0x7fff39a57b08, bailoutInfo=0x7fff39a57b00)
    at /home/andre/git/mozilla-central-master/js/src/jit/Bailouts.cpp:152
#3  0x00007f969c008412 in ?? ()
#4  0x0000000002bd95c8 in ?? ()
#5  0x00007fff39a57b00 in ?? ()
#6  0x0000000000000000 in ?? ()
---

Only one time I got a different stack trace:
---
#0  0x000000000042a4b0 in JSFunction::nonLazyScript (this=<optimized out>)
    at /home/andre/git/mozilla-central-master/js/src/shell/../jsfun.h:315
#1  0x00000000005e2669 in ScriptFromCalleeToken (token=<optimized out>) at /home/andre/git/mozilla-central-master/js/src/jit/IonFrames.h:72
#2  js::jit::JitFrameIterator::script (this=<optimized out>) at /home/andre/git/mozilla-central-master/js/src/jit/IonFrames.cpp:187
#3  0x000000000055f839 in js::jit::BailoutIonToBaseline (cx=cx@entry=0x20fa5b0, activation=activation@entry=0x7fff24c462d0, iter=..., 
    invalidate=invalidate@entry=false, bailoutInfo=bailoutInfo@entry=0x7fff24c460d8, excInfo=0x1, excInfo@entry=0x0)
    at /home/andre/git/mozilla-central-master/js/src/jit/BaselineBailouts.cpp:1336
#4  0x000000000055fe5f in js::jit::Bailout (sp=0x7fff24c460e0, bailoutInfo=0x7fff24c460d8)
    at /home/andre/git/mozilla-central-master/js/src/jit/Bailouts.cpp:101
#5  0x00007ff7b8a7830c in ?? ()
#6  0x00007fff24c460e0 in ?? ()
#7  0x00007fff24c460d8 in ?? ()
#8  0x000000000219c9f0 in ?? ()
#9  0x0000000000000000 in ?? ()
---

Comment 1

[Till Schneidereit [:till]]

Can you give more details on the version of the shell and the OS/compiler (not that I'd think it changes something) you're using? I can't reproduce with current tip.

Comment 2

[André Bargull [:anba]]

Ubuntu x64, gcc4.9.0, mozilla-central at 9e8e3e903484, build-config: configure --enable-debug --enable-debug-symbols

Comment 3

[Till Schneidereit [:till]]

Hmm, given that this only happens in optimized debug builds, I wonder if it's a GCC issue. You don't by any chance have Clang available and could try building with that?

Comment 4

[André Bargull [:anba]]

Sure, I'll try to rebuild using Clang 3.4.

Comment 5

[André Bargull [:anba]]

(In reply to Till Schneidereit [:till] from comment #3)
> Hmm, given that this only happens in optimized debug builds, I wonder if
> it's a GCC issue. You don't by any chance have Clang available and could try
> building with that?

Sorry that it took so long, I first had to struggle with a Clang - GCC4.9 libstdc++ issue. At least I could confirm that it's a GCC issue, there were no assertions when I build the shell with Clang.

Comment 6

[Shu-yu Guo [:shu]]

Andre, could you see what JitFrameIterator think the actual frame type is? You can do something like p iter.type() in gdb.

What's bizarre about that assert is that early on in the BailoutIonToBaseline function, we do JS_ASSERT(iter.isIonJS()): http://dxr.mozilla.org/mozilla-central/source/js/src/jit/BaselineBailouts.cpp?from=BailoutIonToBaseline&case=true#1281

Then you get an assert when calling iter.script(), which says that iter.type() is *neither* IonJS nor Baseline, even though we just asserted that it is IonJS. Guess it could be a GCC bug, because I don't see how that can be possible.

Comment 7

[André Bargull [:anba]]

(In reply to Shu-yu Guo [:shu] from comment #6)
> Andre, could you see what JitFrameIterator think the actual frame type is?
> You can do something like p iter.type() in gdb.

`print type()` returns only "value has been optimized out", which not really helpful...

Comment 8

[André Bargull [:anba]]

Since the assertion does not occur when using gcc4.8, I've tried to find out if this is indeed a bug in gcc4.9. I'm using gcc4.9 from the ubuntu-toolchain ppa (version 4.9-20140406-1ubuntu1), attempts to use a newer gcc4.9 (self build from trunk@r211587) only resulted in a specialization after instantiation error in ScopeObject.h and a different error in jsgcinlines.h because of implicit conversion from std::nullptr_t to bool. :-(

Comment 9

[Nicolas B. Pierron [:nbp]]

(In reply to André Bargull from comment #8)
> Since the assertion does not occur when using gcc4.8, I've tried to find out
> if this is indeed a bug in gcc4.9. I'm using gcc4.9 from the
> ubuntu-toolchain ppa (version 4.9-20140406-1ubuntu1), attempts to use a
> newer gcc4.9 (self build from trunk@r211587) only resulted in a
> specialization after instantiation error in ScopeObject.h and a different
> error in jsgcinlines.h because of implicit conversion from std::nullptr_t to
> bool. :-(

We have another similar issue which is related to gcc4.9. I have no yet got time to check that my-self. (see Bug 1006077)

Based on Bug 1006077, it seems that this issue might be related to new algorithm for inheritance analysis that they use for devirtualization.  I do not know what is the performance impact of it if we only remove this optim on the JS shell when we are compiling with gcc 4.9.

I wonder if we can find it this issue is related to any of the following bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498

We need to find a minimal test case where we can reproduce this issue and report it to them.

Comment 10

[Nicolas B. Pierron [:nbp]]

Nathan, do you know how we can spew compilation information / minimize the JS Shell to get a better understanding / minimal test case of what is going on here.

Comment 11

[André Bargull [:anba]]

Attachment: Patch for gcc4.9 trunk compat

I've just rebuilt the shell with gcc4.9 trunk (after applying the attached patch) and now the assertion is no longer reproducible.

Comment 12

[Nicolas B. Pierron [:nbp]]

(In reply to André Bargull from comment #11)
> Created attachment 8439834 [details] [diff] [review]
> Patch for gcc4.9 trunk compat
> 
> I've just rebuilt the shell with gcc4.9 trunk (after applying the attached
> patch) and now the assertion is no longer reproducible.

Why would this patch suddenly fix this bailout iterator issue?

Comment 13

[André Bargull [:anba]]

The patch does not fix the bailout issue, it's just necessary to fix some compile-time build errors in gcc trunk (see comment #8).

Comment 14

[André Bargull [:anba]]

Oh, and even with the patch applied, compiling with gcc4.9-20140406 still results in the assertion. So the patch does not change anything in this regard, it's just necessary to compile the shell at all.

Comment 15

[Nathan Froyd [:froydnj]]

(In reply to Nicolas B. Pierron [:nbp] from comment #10)
> Nathan, do you know how we can spew compilation information / minimize the
> JS Shell to get a better understanding / minimal test case of what is going
> on here.

I think the first step would be to figure out what's getting miscompiled.  So something like:

1. Produce preprocessed files for all shell .cpp files, doing this with a known-good, older compiler.  (Do this so you--ideally--don't have issues with libstdc++ versions used by different compilers getting in the way.)
2. Compile preprocessed files with known-good compiler (GCC 4.7/GCC 4.8?)--just compile, don't link.
3. Compile preprocessed files with GCC 4.9 in the same way.
4. For each object file from the bad compiler, link it with all the other objects from the known-good compiler, using the known-good compiler to link so you pick the correct symbols from libstdc++ etc.
5. Test.  If it's good, repeat step 4.  If it asserts, you have found a miscompilation.

Then perhaps you can start staring at what's going wrong in that file, assembly diffs, individual function sizes, -fdump-tree-all, etc.

Looking at the 4.9 changes, it sounds like -fno-devirtualize-speculatively might be useful.  -fno-devirtualize separately or on top of that might also be useful.

Comment 16

[Nathan Froyd [:froydnj]]

Oh, I guess we have a function that's supposedly miscompiled already?  That might just be a matter of either comparing assembly, or -fdump-tree-all with the good/bad compilers and comparing those dumps (starting with ones past .ssa or so).  Happy to provide more guidance if somebody wants to grovel through those dumps.

Comment 17

[Nicolas B. Pierron [:nbp]]

André, apparently gcc 4.9 (from SVN) no longer present such issue, can you try what glandium reported in Bug 1006077 comment 25?

Comment 18

[André Bargull [:anba]]

(In reply to Nicolas B. Pierron [:nbp] from comment #17)
> André, apparently gcc 4.9 (from SVN) no longer present such issue, can you
> try what glandium reported in Bug 1006077 comment 25?

Which issue do you mean? The assertion failure in isScripted() or the gcc compiler errors mentioned in comment #8?
Like I said in comment #11, when I rebuilt SpiderMonkey with a more recent gcc (in that case it was gcc trunk@r211589), the assertion failure could not be reproduced.

Comment 19

[Nicolas B. Pierron [:nbp]]

(In reply to André Bargull from comment #18)
> (In reply to Nicolas B. Pierron [:nbp] from comment #17)
> > André, apparently gcc 4.9 (from SVN) no longer present such issue, can you
> > try what glandium reported in Bug 1006077 comment 25?
> 
> Which issue do you mean? The assertion failure in isScripted() or the gcc
> compiler errors mentioned in comment #8?
> Like I said in comment #11, when I rebuilt SpiderMonkey with a more recent
> gcc (in that case it was gcc trunk@r211589), the assertion failure could not
> be reproduced.

Sorry, I missed your comment before, so I will mark this bug as a duplicate of Bug 1006077, as this was a gcc 4.9 issue and they fixed it upstream.

Thanks for investigating :)

Comment 20

[André Bargull [:anba]]

Is there any interest to fix compile time errors from comment #8? If yes, I'd create a new bug report.

---
In file included from /home/andre/git/mozilla-central-master/js/src/jsobjinlines.h:16:0,
                 from /home/andre/git/mozilla-central-master/js/src/builtin/RegExp.cpp:17:
/home/andre/git/mozilla-central-master/js/src/vm/ScopeObject.h:917:39: error: specialization of 'bool JSObject::is() const [with T = js::StaticBlockObject]' after instantiation
 JSObject::is<js::StaticBlockObject>() const
                                       ^
In file included from /home/andre/git/mozilla-central-master/js/src/jsalloc.h:18:0,
                 from /home/andre/git/mozilla-central-master/js/src/jsatom.h:12,
                 from /home/andre/git/mozilla-central-master/js/src/vm/Runtime.h:20,
                 from /home/andre/git/mozilla-central-master/js/src/jscntxt.h:15,
                 from /home/andre/git/mozilla-central-master/js/src/vm/RegExpObject.h:13,
                 from /home/andre/git/mozilla-central-master/js/src/builtin/RegExp.h:10,
                 from /home/andre/git/mozilla-central-master/js/src/builtin/RegExp.cpp:7:
/home/andre/git/mozilla-central-master/js/src/jsgcinlines.h: In function 'bool js::gc::PossiblyFail()':
../../dist/include/js/Utility.h:88:20: error: converting to 'bool' from 'std::nullptr_t' requires direct-initialization [-fpermissive]
             return nullptr; \
                    ^
/home/andre/git/mozilla-central-master/js/src/jsgcinlines.h:533:5: note: in expansion of macro 'JS_OOM_POSSIBLY_FAIL'
     JS_OOM_POSSIBLY_FAIL();
---