Find it and CL did not provide any possible suspects.
Using code Search for the file, "LayoutUnit.h" assigning to the concern owner.
Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/031e22e5ca256199390180d5ffbb9cf182c36664

@eae -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

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

commit 47305a33360149240ab99c57c6c65ff5f05fa68e
Author: mstensho <mstensho@opera.com>
Date: Thu Feb 23 19:19:14 2017

Avoid negative content box sizes.

Negative values had two possible causes:

1. Subtracting the scrollbar size from the border box size. Scrollbars do not
affect the border box size, but they occupy space between some border edge and
padding edge. This means that the presence of a scrollbar on an object reduces
the size of the content box and the containing block established by said
object. This means that if e.g. the specified width of an object is 10px and it
has a vertical scrollbar that takes up more than that, e.g. 15px, the content
box width should become 0, not -5px.

2. Subtracting two huge (or even saturated) LayoutUnit values from one
LayoutUnit value. When we during layout convert a specified content-box width
to border-box (via padding-box), which is what LayoutBox::m_frameRect uses, we
may end up with saturated LayoutUnit values, so that:
LayoutUnit specified_content_box_width = <whatever, something nice, maybe>;
LayoutUnit left_padding = LayoutUnit::max() /*(or something huge, at least)*/;
LayoutUnit right_padding = LayoutUnit::max() /*(or something huge, at least);*/
LayoutUnit padding_box_width = content_box_width + left_padding + right_padding;
LayoutUnit content_box_width = padding_box_width - left_padding - right_padding;
Here, content_box_width won't be the same as specified_content_box_width,
because padding_box_width got saturated. That's kind of inevitable, with
saturated arithmetic and all, but what's worse is that we used to end up with a
negative value in content_box_width, which is illegal. So just clamp negative
values to 0 to avoid that.

Negative box sizes have various kinds of ill effects, such as inline-axis
misalignment and unwanted negative block direction progression. It was possible
to get negative padding (which is illegal) resolved from percentage values.
This in turn caused unnecessary assertion failures in multicol.

Attempted to come up with sensible layout tests that don't make assumptions
about how the engine deals with extreme values internally.

BUG= 683554 , 683090 

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

[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/block/large-border-abspos.html
[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/block/large-padding-vertical-writing-mode.html
[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/block/large-padding.html
[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/block/scrollbar-wider-than-border-box.html
[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/multicol/large-padding-crash.html
[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/multicol/scrollbar-wider-than-content-box-crash.html
[modify] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/Source/core/layout/LayoutBox.h

ClusterFuzz has detected this issue as fixed in range 452556:452642.

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

Fuzzer: bj_broddelwerk
Job Type: linux_lsan_chrome_mp
Platform Id: linux

Crash Type: Floating-point-exception
Crash Address: 
Crash State:
  intMod
  blink::LayoutMultiColumnSet::pageRemainingLogicalHeightForOffset
  adjustedMarginBeforeForPagination
  
Sanitizer: address (ASAN)

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_lsan_chrome_mp&range=437053:437094
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_lsan_chrome_mp&range=452556:452642

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv96E8y_M4Tm2Weq-USzzDe2lfys9q8D3qvLZ6uEtsKyZFlyq6PliPriL8fQ88YYZeseIjcIOqltPFJKps1RpS1AVX_0IaDI7IKKEa8sx4AgGnBfJMOOFJtFWIjcuN35o2nkRuaQFXRu6ySFF5yry7_o_VDaNeQndrUDcqoLHN3D3pkehqqhkzt0bl-vOCahN21smIBAYhuCBsJfInb1vi0wpIf8revoEhMqSn_LohAZNbVdnwpOjjxoj7TgQv-Tc9h7pY47Fv6whJ6Om4cOwz1xdCsS6VkdAS3iwwUbt8AUd3uzIjWO2q44xlQendy1cx4Sp-yoOCe6d9HsN8nThju5pqnIy485eGHZWV2PXNQs2ZL8rQaw?testcase_id=6473309014458368


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.

How can i set it

Android samsung Galaxcy j7

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

commit 0b389da84405eef38ee9f9e54f51352a6c1508f3
Author: mstensho <mstensho@opera.com>
Date: Mon Feb 27 13:47:02 2017

Allow flow thread portion logical bottom to be above its logical top.

We used to try to prevent this, as an attempt to make sure that no
fragmentainer group would have overlapping flow thread portion rectangles with
other fragmentainer groups. But that was already easily achievable with e.g. an
empty block between two column spanners anyway.

There is a legitimate reason for the flow thread portion bottom to be above the
top: negative margins.

Introduce MultiColumnFragmentainerGroup::logicalHeightInFlowThreadAt().
Less duplicated code. Some extra care is now needed, to make sure that we don't
end up with negative logical heights.

BUG= 688760 , 683090 , 683554 

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

[add] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/LayoutTests/fast/multicol/span/spanner-after-negative-margin-bottom-crash-2.html
[add] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/LayoutTests/fast/multicol/span/spanner-after-negative-margin-bottom-crash.html
[modify] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/Source/core/layout/LayoutMultiColumnFlowThread.cpp
[modify] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/Source/core/layout/LayoutMultiColumnSet.h
[modify] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.cpp
[modify] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.h