Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Predator has provided 5 possible suspects.

1. Remove WebBlendMode from WebLayer API, use SkBlendMode directly. by danakj@chromium.org
2. Replace uses of WTF::AutoReset with base::AutoReset. by jbroman@chromium.org
3. Correct OverflowClipRect() for root scroller by bokan@chromium.org
4. Add CHECK to diagnose unexpected document lifecycle transition. by szager@chromium.org
5. [LayoutNG] Need to pre-layout legacy orthogonal writing mode roots. by mstensho@chromium.org

Suspect CL:
===========
https://chromium.googlesource.com/chromium/src/+/b68698e6c0c71af8f3b667ad547fc9d7ca2d1ef3

danakj@ Could you please look into this issue.

IntRect LayoutBox::AbsoluteContentBox() const {
  // This is wrong with transforms and flipped writing modes.
  IntRect rect = PixelSnappedIntRect(PhysicalContentBoxRect());
  FloatPoint abs_pos = LocalToAbsolute();
  rect.Move(abs_pos.X(), abs_pos.Y());  <--- This is overflowing.
  return rect;
}

This isn't related to blend mode. Sounds like layout.

Simplified test attached. It still has SVG in it, but I doubt it's relevant. Anyway, it's LayoutSVGRoot::LocalToBorderBoxTransform() that returns a mad transform.

Deleted: tc-svg.html 226 bytes

tc-svg.html 226 bytes View Download

With this (available) width and that viewBox, a fairly large scale-factor - LayoutUnit::max() / 87 or so - seems to be expected.

This code (AbsoluteContentBox, and it's caller to some degree) seems to be mixing different representations quite a bit (LayoutUnit to int adding a float and then converting to LayoutUnit again in the caller...)

Using more LayoutUnit to get saturated fixed-point arithmetic might fix it, but I'd like to understand the extent of the problem first.

Here's a better test. My previous one didn't really cause integer overflow (just something still very big). Still with SVG.

Deleted: tc-better.html 228 bytes

tc-better.html 228 bytes View Download

Yes, I think the "origin" of the issue is the same here - you get a scale-factor within the SVG that is "fairly large", which will then end up applying to the (huge) margin.

The special thing about SVG here, is that SVGLayoutSupport::MapLocalToAncestor(), unlike regular layout code, doesn't check MapCoordinatesFlags to verify that kUseTransforms is set (which isn't set in this case) before applying transforms. But I guess that's how it has to be? Anyway, to me it seems reasonable to allow it.

Fix by using saturated arithmetic: https://chromium-review.googlesource.com/c/chromium/src/+/1245782

Yes, kUseTransforms is pretty much assumed within SVG (even if it wasn't we'd still have to apply part of the transform.) (Also, not using kUseTransforms should probably be frowned upon in general...)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/859079e80572749ed2e96d702cdad7acd7c216d9

commit 859079e80572749ed2e96d702cdad7acd7c216d9
Author: Morten Stenshorne <mstensho@chromium.org>
Date: Tue Oct 02 08:19:48 2018

Remove LayoutBox::AbsoluteContentBox*().

AbsoluteContentBox() used to cast directly from float to int, and if
the float value was sufficiently large, we'd end up with a negative
integer value.
Changed the two former callsites to using PhysicalContentBoxRect() +
LocalToAbsolute() instead.

AbsoluteContentBoxOffset() was unused.

Bug:  888510 
Change-Id: Id1447973f23cabf40a45180aa95a69ba402688c6
Reviewed-on: https://chromium-review.googlesource.com/1245782
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595758}
[modify] https://crrev.com/859079e80572749ed2e96d702cdad7acd7c216d9/third_party/blink/renderer/core/layout/layout_box.cc
[modify] https://crrev.com/859079e80572749ed2e96d702cdad7acd7c216d9/third_party/blink/renderer/core/layout/layout_box.h
[modify] https://crrev.com/859079e80572749ed2e96d702cdad7acd7c216d9/third_party/blink/renderer/modules/canvas/canvas2d/canvas_rendering_context_2d.cc

Fixed by removing the method with broken code. :)

\o/

ClusterFuzz has detected this issue as fixed in range 595757:595758.

Detailed report: https://clusterfuzz.com/testcase?key=4632238405451776

Fuzzer: ifratric-browserfuzzer-v3
Job Type: linux_ubsan_chrome
Platform Id: linux

Crash Type: Float-cast-overflow
Crash Address: 
Crash State:
  blink::LayoutBox::AbsoluteContentBox
  blink::LayoutBox::ComputeResourcePriority
  blink::PriorityFromObserver
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=551565:563900
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=595757:595758

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4632238405451776

See https://github.com/google/clusterfuzz-tools for more information.

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

ClusterFuzz testcase 4632238405451776 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.