Reproduces on TOT, bisects to "[Interpreter] Make ignition compiler eagerly" (https://codereview.chromium.org/1811553003).

Fails without --ignition and with --no-lazy, so looks like it's something to do with eager parsing / compiling rather than specific to ignition. I'll dig a bit deeper. 

It looks as if there is a difference in the AST for __v_38 generated during the initial eager compile, and the second lazy compile (for optimizing). 

This is the AST for the initial eager compile:

--- AST ---
FUNC at 319
. KIND 0
. YIELD COUNT 0
. NAME ""
. INFERRED NAME "__v_38.m"
. RETURN at 333
. . PROPERTY Slot(2) at 346
. . . VAR PROXY Slot(0) lookup (mode = DYNAMIC_LOCAL) "__v_38"
. . . NAME a

And this is the AST for the followup lazy compile (for optimization):

. KIND 0
. YIELD COUNT 0
. NAME ""
. INFERRED NAME "__v_38.m"
. RETURN at 333
. . PROPERTY Slot(0) at 346
. . . VAR PROXY context[7] (mode = VAR) "__v_38"
. . . NAME a

If "--no-lazy" isn't set then we get the second AST for all compilations. It looks like the parser is not being consistent about whether the "__v_38" lookup should be a context load (on the lazy compiles) or a lookup load (on the eager compiles), which then causes a mismatch on the number of feedback vector slots. 

The bug only seems to exhibit itself when the code is in a catch block and when there is also an eval in that catch block. 

Adam / Andreas - Any ideas what might be going on?

Having stepped through this, I can start to tell you very specifically why this gets a different mode: the first time, the catch scope is marked as calling eval, while the second time (after scope deserialization), it isn't.

Beyond that, still digging. But I should also say that this particular logic about what ends up as BOUND_EVAL_SHADOWED (and thus DYNAMIC_LOCAL) seems over-aggressive. Unless I'm missing something, an eval in a catch scope shouldn't be able to shadow var bindings in the surrounding function (those bindings will be hoisted to the function level anyway).

Okay, the reason that the "calls eval" bit isn't carried along is just that CatchContexts don't hold a ScopeInfo, so there's nowhere to store that bit (though as I said the fact that the catch scope calls eval shouldn't affect shadowing).

Fix up for this particular case at: https://codereview.chromium.org/1950803002/

Thanks for the fix Adam!

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

commit 75f2d65f003ebb22815489e9970913ba37234f1b
Author: adamk <adamk@chromium.org>
Date: Wed May 04 21:34:43 2016

Don't treat catch scopes as possibly-shadowing for sloppy eval

Scope analysis is over-conservative when treating variable resolutions
as possibly-shadowed by a sloppy eval. In the attached bug, this comes
into play since catch scopes have different behavior with respect to
the "calls eval" in eager vs lazy compilation (in the latter, they
are never marked as "calls eval" because CatchContexts don't have
an associated ScopeInfo).

This patch changes the scope-type check to also eliminate a few other
cases where shadowing isn't possible, such as non-declaration block scopes.

BUG= chromium:608279 
LOG=n

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

[modify] https://crrev.com/75f2d65f003ebb22815489e9970913ba37234f1b/src/ast/scopes.cc
[add] https://crrev.com/75f2d65f003ebb22815489e9970913ba37234f1b/test/mjsunit/regress/regress-crbug-608279.js

ClusterFuzz has detected this issue as fixed in range 36045:36046.

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

Fuzzer: mbarbella_js_mutation
Job Type: linux_asan_d8_ignition_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !info->shared_info()->feedback_vector()->metadata()->SpecDiffersFrom( info->lite
  
Regressed: V8: r35065:35066
Fixed: V8: r36045:36046

Minimized Testcase (0.20 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv964kpNlRokJhuKPg7ZtgR1qswRsCn2IFMzRGqzJBY_wG5h0rGosRQLLnlo0THH1wXNM8RWojCSMgfDolHEooPSIzYWjEsHF325HBohCFMZvVcJZYhW4J208t051C0iK6K7ygnZIR3QVSL_aScWguEFBxjvGJA
function __f_38() {
  try {
    throw 0;
  } catch (e) {
 eval();
      var __v_38 = { a: 'hest' };
      __v_38.m = function () { return __v_38.a; };
  }
  return __v_38;
}
var __v_40 = __f_38();
 __v_40.m();


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.

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