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

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

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/d54494cbad8d5ff0a8cd74024902c8bd86258ae4 (Roll clang 338452:340925).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

I don't think the Clang roll regressed this, but it may well have made UBSan more sensitive. The stack looks like this:

../../third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc:318:10: runtime error: 2.14748e+09 is outside the range of representable values of type 'int'
 #0 0x5558ce416123 in CornerStart third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc
 #1 0x5558ce416123 in blink::PaintLayerScrollableArea::CornerRect(blink::IntRect const&) const third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc:341
 #2 0x5558ce41f188 in blink::PaintLayerScrollableArea::ResizerCornerRect(blink::IntRect const&, blink::ResizerHitTestType) const third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc:1760:20

First off, 2.14748e+09 is suspiciously close to the max value that int holds. Maybe it's been rounded somewhere to be slightly too large?

If the code is supposed to handle large float values, perhaps the cast from float to int should be done with saturated_cast?

But I suspect such a large value for BorderRightWidth doesn't make sense, so maybe the real question is how we end up with such a large value there.