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

Reporter

Description

•

10 years ago

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 ?? ()
---

Till Schneidereit [:till]

Comment 1

•

10 years ago

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.

André Bargull [:anba]

Reporter

Comment 2

•

10 years ago

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

Till Schneidereit [:till]

Comment 3

•

10 years ago

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?

André Bargull [:anba]

Reporter

Comment 4

•

10 years ago

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

André Bargull [:anba]

Reporter

Comment 5

•

10 years ago

(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.

Shu-yu Guo [:shu]

Comment 6

•

10 years ago

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.

André Bargull [:anba]

Reporter

Comment 7

•

10 years ago

(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...

André Bargull [:anba]

Reporter

Comment 8

•

10 years ago

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. :-(

Nicolas B. Pierron [:nbp]

Comment 9

•

10 years ago

(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

•

10 years ago

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.

Flags: needinfo?(nfroyd)

André Bargull [:anba]

Reporter

Comment 11

•

10 years ago

Attached patch Patch for gcc4.9 trunk compat — Details — Splinter Review

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

Nicolas B. Pierron [:nbp]

Comment 12

•

10 years ago

(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?

André Bargull [:anba]

Reporter

Comment 13

•

10 years ago

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).

André Bargull [:anba]

Reporter

Comment 14

•

10 years ago

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.

Nathan Froyd [:froydnj]

Comment 15

•

10 years ago

(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.

Flags: needinfo?(nfroyd)

Nathan Froyd [:froydnj]

Comment 16

•

10 years ago

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.

Nicolas B. Pierron [:nbp]

Comment 17

•

10 years ago

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

Flags: needinfo?(andrebargull)

André Bargull [:anba]

Reporter

Comment 18

•

10 years ago

(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.

Flags: needinfo?(andrebargull)

Nicolas B. Pierron [:nbp]

Comment 19

•

10 years ago

(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 :)

Status: NEW → RESOLVED

Closed: 10 years ago

Resolution: --- → DUPLICATE

André Bargull [:anba]

Reporter

Comment 20

•

10 years ago

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();
---