Bisects to: https://chromium.googlesource.com/v8/v8/+/a3c13435aa822041b1fac25baf0e63c56185e4a1

Reproduces as follows ...

$ ./out/x64.debug/d8 --random-seed=1532034190 --turbo --always-opt ~/Downloads/fuzz-00474.js 

#
# Fatal error in ../src/frames.cc, line 1140
# Missing deoptimization information for OptimizedFrame::Summarize.
#

Looking into this.

All this patch did to change how that particular input is handled was move the exception throwing from JS to the runtime function TypedArrayInitialize.

However, what's special is that the call to TypedArrayInitialize is as an inline intrinsic (with a "%_" prefix). If I change it to %TypedArrayInitialize, everything works as expected. So it seems our OptimizedFrame walking code may not properly handle the case of an exception thrown from a runtime function called as an intrinsic (at least for the TurboFan case).

Indeed, I can reproduce elsewhere by taking any runtime call that throws and calling it with a "%_" prefix, e.g.:

d8 -e 'var obj = Object.freeze({}); %_CreateDataProperty(obj, "foo", "bar");' --allow-natives-syntax --always-opt --turbo

This also crashes with the same check failure in OptimizedFrame::Summarize.

+jgruber as well, as this may just be due to recent changes in the stack-walking code.

Chasing this down further, I think this is a bug in Linkage::NeedsFrameStateInput(). If I modify that code to return true for Runtime::kInlineTypedArrayInitialize, then this test case goes back to not crashing.

I think the right general fix would be for NeedsFrameStateForInput to know which runtime calls that appear inline will actually turn out to be runtime calls; right now I believe that logic is in js-intrinsic-inlining. I'm happy to do the work (it's probably just factoring out some switch statements), but I don't know what the best way to structure that would be.

Assigning to bmeurer for thoughts on how to organize this logic (and retitling).

I think the idea initially was that intrinsics wouldn't be allowed to throw (or even lazy deopt), while regular runtime functions can do everything. But as far as I can remember that never really worked due to our use of %_ intrinsics in so many interesting ways.

So I think the correct fix nowadays is to explicitly white-list everything that doesn't throw and/or lazy deopt in Linkage::NeedsFrameStateInput, instead of having a blacklist for %_ intrinsics and a white-list for % functions. That seems safer and we can still leave out frame states when we know it's OK to do so.

I'd be happy if you could take a look.

Whitelist instead of blacklist seems ok to me (even the whitelist is a little scary, but I agree it's definitely safer than the blacklist).

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/58325e616d068ab589a91b6f80896e28df395f93

commit 58325e616d068ab589a91b6f80896e28df395f93
Author: adamk <adamk@chromium.org>
Date: Mon Sep 12 16:12:13 2016

[turbofan] Switch from a whitelist to a blacklist for NeedsFrameStateInput

The whitelist is populated with those inline intrinsics that are lowered
in JSIntrinsicInlining and were not previously blacklisted. Thus the only
additional FrameStates this CL adds are those where the caller tries to
call the INLINE version of an intrinsic but ends up calling the RUNTIME
version instead.

R=bmeurer@chromium.org
BUG= chromium:644631 

Review-Url: https://codereview.chromium.org/2331543002
Cr-Commit-Position: refs/heads/master@{#39357}

[modify] https://crrev.com/58325e616d068ab589a91b6f80896e28df395f93/src/compiler/linkage.cc
[add] https://crrev.com/58325e616d068ab589a91b6f80896e28df395f93/test/mjsunit/regress/regress-crbug-644631.js

ClusterFuzz has detected this issue as fixed in range 39347:39359.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4872750261075968

Fuzzer: mbarbella_js_mutation
Job Type: linux_v8_d8_tot
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  Missing deoptimization information for OptimizedFrame::Summarize in frames.cc
  
Regressed: V8: r38677:38693
Fixed: V8: r39347:39359

Minimized Testcase (0.10 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv966VZ_5CpG0HisQ6Z_u5vf0P7VHVNXbYZaMvoEelOFPHET2dEPNriRIGEl5QItrc4o6Y__QS5iBrGjsSCPfkQltKkH59L7cuOQmN2iSiByjPGpzTqp-9-kUqOTFN7q_B7Y8QRNTK23EMunQzlPQHhYjrtlxiA?testcase_id=4872750261075968
__v_4 = this;
__v_5 = new ArrayBuffer(-1 * -2147483648);
  var __v_2 = new __v_4.Int8Array(__v_5);


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/1eaf2927bac050b466f490082e55a2dbf6a2648d

commit 1eaf2927bac050b466f490082e55a2dbf6a2648d
Author: adamk <adamk@chromium.org>
Date: Wed Oct 12 07:33:05 2016

Change TF regression test to not trigger tons of allocation

Instead of allocating an ArrayBuffer in the test, use a different example
from the original bug.

R=bmeurer@chromium.org
BUG= chromium:644631 ,  v8:5504 

Review-Url: https://codereview.chromium.org/2408403002
Cr-Commit-Position: refs/heads/master@{#40195}

[modify] https://crrev.com/1eaf2927bac050b466f490082e55a2dbf6a2648d/test/mjsunit/regress/regress-crbug-644631.js

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot