New issue
Advanced search Search tips

Issue 2326 link

Starred by 5 users

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2012
Cc:
HW: ----
NextAction: ----
OS: ----
Priority: 1
Type: Bug



Sign in to add a comment

Fatal error: CHECK(BailoutId(data->OsrAstId()->value()) == ast_id) failed

Reported by jason.da...@gmail.com, Sep 8 2012

Issue description

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/
 
crossfilter.js
36.6 KB View Download
bug.js
528 bytes View Download
debug.js
37.6 KB View Download
trace.txt
4.4 KB View Download
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.
Cc: danno@chromium.org jkummerow@chromium.org
Labels: Type-Bug Priority-High
Owner: mstarzinger@chromium.org
Status: Assigned
I'll look into that.
Thanks, let me know if you need any further information.
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.
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 |
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?
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 |
Status: Fixed
Fixed in r12504.
Fantastic, thank you!
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!
Yes, we need to merge this back to V8 3.13 and 3.12 branches. I will make sure it gets merged back.
 Issue chromium:153765  has been merged into this issue.
Great, thank you. Do you know roughly how long it will take to hit Chrome stable?
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.
Merged to V8 3.13 branch (Chrome M23) in v8:r12716.

https://code.google.com/p/v8/source/detail?r=12716
 Issue chromium:153765  has been merged into this issue.
Labels: Priority-1

Sign in to add a comment