Status: New
Owner: ----

New issue 2326 by jason.da...@gmail.com: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

I first noticed this when testing in Chrome 22.0.1229.39 beta and  
23.0.1259.1 canary.

It seems a critical bug can be reliably reproduced when using the  
in-browser database Crossfilter [1] and executing the same few simple  
filters in sequence.

I investigated and managed to reproduce this using a simple test case in  
both V8 3.12 and latest master:  
https://v8.googlecode.com/svn/branches/bleeding_edge@12470

When using ia32.release, there is no error but the printed count is  
incorrect. It should be 600000, and I get something like 119638.

When using ia32.debug, there is a fatal error, the trace for which is  
attached.

Lastly, this problem doesn't appear to occur in Chrome stable, 21.0.1180.89.

The attached files are:
- crossfilter.js, the stock version of Crossfilter in use.
- bug.js, the test case
- debug.js, the combined crossfilter.js and 2x bug.js (it usually needs to  
be run twice to reproduce/activate the JIT).
- trace.txt, the trace when ia32.debug is used.

[1]: http://square.github.com/crossfilter/

Attachments:
        crossfilter.js  36.6 KB
        bug.js  528 bytes
        debug.js  37.6 KB
        trace.txt  4.4 KB

Comment #1 on issue 2326 by jason.da...@gmail.com: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

I think the function where it's going wrong is filterIndex(bounds). In  
particular, it seems like one of the if-statement conditionals is  
completely ignored:

       // Fast incremental update based on previous hi index.
       if (hi1 > hi0) {
         for (i = Math.max(lo1, hi0), j = hi1; i < j; ++i) {
           filters[k = index[i]] ^= one;
           added.push(k);
         }
       }

I've tried inserting console.log statements here and this block seems to  
execute when hi1 <= hi0, leading to incorrect results.

Updates:
        Status: Assigned
        Owner: mstarzin...@chromium.org
        Cc: da...@chromium.org jkumme...@chromium.org
        Labels: Type-Bug Priority-High

Comment #2 on issue 2326 by mstarzin...@chromium.org: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

I'll look into that.

Comment #3 on issue 2326 by jason.da...@gmail.com: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

Thanks, let me know if you need any further information.

Comment #4 on issue 2326 by mstarzin...@chromium.org: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

I am able to reproduce. It seems to be another bug in sharing of optimized  
code. If I run with --nocache-optimized-code, then the issue disappears.  
Will investigate further.

Comment #5 on issue 2326 by mstarzin...@chromium.org: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

And yes, your initial guess that it has to do with filterIndex() was right,  
that is the only code that is shared, and that happens right before the  
assertion. If you run with --trace-opt you get this:

[found optimized code for: filterIndex / 26242e35]

We also share optimized code in our fast new closure stub, however  
--dump-counters reveals that this wasn't the case for the code at hand:

c:V8.FastNewClosureInstallOptimized | 0 |
c:V8.FastNewClosureTotal            | 0 |
c:V8.FastNewClosureTryOptimized     | 0 |

Comment #6 on issue 2326 by jason.da...@gmail.com: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

Interesting, thanks for looking into this!

It seems I'm unable to obtain the counters output when a fatal error occurs  
though, did you check for the error when generating your counters output  
above?

Comment #7 on issue 2326 by jason.da...@gmail.com: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

Ah, but I've verified your counters output using ia32.release, sorry for  
the noise:

| c:V8.FastNewClosureInstallOptimized                            
|           0 |
| c:V8.FastNewClosureTotal                                        
|           0 |
| c:V8.FastNewClosureTryOptimized                                
|           0 |

Updates:
        Status: Fixed

Comment #8 on issue 2326 by mstarzin...@chromium.org: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

Fixed in r12504.

Comment #9 on issue 2326 by jason.da...@gmail.com: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

Fantastic, thank you!

Comment #10 on issue 2326 by jason.da...@gmail.com: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

It looks like this bug may have reached Chrome stable (22.0.1229.79):  
https://github.com/square/crossfilter/issues/40

What's the best way to make sure this fix is included in Chrome stable?  
It's quite serious as it affects all JavaScript applications that use  
Crossfilter.

(If there is a temporary workaround, that might be useful to know, too.)

Thanks!

Comment #11 on issue 2326 by mstarzin...@chromium.org: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

Yes, we need to merge this back to V8 3.13 and 3.12 branches. I will make  
sure it gets merged back.

Comment #12 on issue 2326 by jkumme...@chromium.org: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

Issue chromium:153765 has been merged into this issue.

Comment #13 on issue 2326 by jason.da...@gmail.com: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

Great, thank you. Do you know roughly how long it will take to hit Chrome  
stable?

Comment #14 on issue 2326 by mstarzin...@chromium.org: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

Usually it would take less than a week to hit Chrome Canary. Unfortunately  
we currently have a hard time stabilizing V8 bleeding edge so I cannot give  
a time-frame in this case. And without Canary coverage we cannot merge to  
stable channels. I'll update the issue when I have news.

Comment #15 on issue 2326 by mstarzin...@chromium.org: Fatal error:  
CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed
http://code.google.com/p/v8/issues/detail?id=2326

Merged to V8 3.13 branch (Chrome M23) in v8:r12716.

https://code.google.com/p/v8/source/detail?r=12716