Just a quick note: the commit links are wrong; the hashes refer to the v8 repository: https://chromium.googlesource.com/v8/v8.git.

Also forgot to remove the template header info at the top of the message. Sorry!

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=5166425964806144

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=5739662532673536

bmeurer@ -- could you please take a look at this issue?

My guess is that it may be related to this CL: https://chromium.googlesource.com/v8/v8/+/8201579e031aee4118e7a98ac0991418d01fd06a%5E%21/src/compiler/typer.cc

If you are not the right owner, please help triage this bug and find the right owner asap. Thanks.

Simplified repro:

function foo(x) {
  (x
   ? (!0 / 0)
   : x) | 0
}

foo(1);
foo(2);
%OptimizeFunctionOnNextCall(foo);
foo(3);

The problem here is that we have a truncation for the NumberDivide, which we take, but then need to produce a tagged value due to the ?: expression. But at that point we only have the original type on the NumberDivide, which is Number, and so we don't know whether we need to treat the truncated word32 value as signed or unsigned. This does actually apply to basically all the Number operations, i.e. we can probably create an example where this crashes for all Number operations that can be produce Numbers, and utilize truncations to decide to produce Word32 values.

The quick fix (which is back-mergable) is probably to just not propagate the truncation for Phi, Select and TypeGuard if the output representation is tagged. The better solution after this is quickfixed is likely to just use the restriction_type as well for truncations, i.e. when you take a truncation you also restrict the output type accordingly, so the lowering phase will have correct type information to make the decision.

I don't think this crash1 example is a security issue tho, because it will just run into V8_Fatal, which immediately turns into Aw Snap for the tab.

Not sure about crash2, but that seems unrelated.

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

commit 8af781ea8220f5fa70bef616e5779cee21064543
Author: mvstanton <mvstanton@chromium.org>
Date: Mon Sep 05 20:54:27 2016

[turbofan] Don't propagate truncations if output is tagged.

Disable the propagation of truncations through Phi, Select or TypeGuard
if the output representation is tagged, because when the truncations are
taken we don't necessarily reflect this in the types and therefore we
might end up in a situation where we produce a word32 value, the type
says Number, and now we need to change that to tagged, which is not
possible since we don't know how to interpret the bits, i.e. whether the
value is Signed32 or Unsigned32.

BUG= chromium:644048 

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

[modify] https://crrev.com/8af781ea8220f5fa70bef616e5779cee21064543/src/compiler/simplified-lowering.cc
[add] https://crrev.com/8af781ea8220f5fa70bef616e5779cee21064543/test/mjsunit/compiler/regress-644048.js

Just want to note that the new tip of v8 no longer crashes on my input crash1.txt, but running: 

valgrind ./d8 crash1.txt

still yields a bunch of "Conditional jump or move depends on unitialised value(s)", and the shell hangs forever. This occurs in all builds when running valgrind ./d8 crash2.txt.

You mentioned this might be a separate issue, do you want to take a look or should I open up a separate bug? Are the valgrind errors/ the hanging anything to be concerned about?

I think it would be useful to track that in a separate bug.

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

commit 01cc19fa6f76511f3cc88e0af795620c913b8304
Author: jarin <jarin@chromium.org>
Date: Tue Sep 06 20:57:30 2016

[turbofan] Handle word32 truncation in word32->tagged representation change.

Similarly to the word32->float64 case, we interpret word32 as uint32 if
the value is word32 truncated. This is fine because the users declared
they only care about mod 2^32 of the value (that's what word32
truncation means).

This CL also removes the ad-hoc handling of this situation
(https://codereview.chromium.org/2311903002).

BUG= chromium:644048 

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

[modify] https://crrev.com/01cc19fa6f76511f3cc88e0af795620c913b8304/src/compiler/representation-change.cc
[modify] https://crrev.com/01cc19fa6f76511f3cc88e0af795620c913b8304/src/compiler/representation-change.h
[modify] https://crrev.com/01cc19fa6f76511f3cc88e0af795620c913b8304/src/compiler/simplified-lowering.cc

Sorry for the bother, but will this bug be eligible for a security reward/a review from the panel?

I believe this is a stability bug, not a security bug. (We have an always-on assertion there, so we will do a controlled crash here.)

Why do you think it is a security bug?

no strong reason, just thought I'd ask since the label Bug-Security hasn't been removed yet :)