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/+/6534acd9b94a260ccf88ccdfd7ab8b3859349082 ([css-grid] Baseline alignment inside the tracks sizing algorithm).

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.

Able to reproduce the issue and indeed caused by the identified CL

Attached reduced test case.

I'm already working on this. 

Deleted: crash-baseline-patch.html 99 bytes

crash-baseline-patch.html 99 bytes View Download

 Issue 847783  has been merged into this issue.

 Issue 847709  has been merged into this issue.

Ok, I think I've figure out the root cause of the issue. In the CL which caused this regression, we were moving up the baseline offset computation before the track sizing algorithm execution. We did that in order to comply with the spec so that the baseline shims should account for the content-sized track size during the tracks sizing algorithm.

The root cause is that current implementation of Grid Layout considers relative sized tracks as content-sized  during intrinsic size. So, items are treated as not able to participate in baseline alignment before running the track sizing, but later, we handled them as if they were allowed to participate in the alingment logic that happens during the layout.

Attached a test case that doesn't involve auto-flow

Deleted: crash-baseline-patch.html 103 bytes

crash-baseline-patch.html 103 bytes View Download

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

commit e77783c0213b9e81c2cebbd7c52e09e4c8a5d6e1
Author: Javier Fernandez <jfernandez@igalia.com>
Date: Tue Jun 05 12:31:16 2018

[css-grid] Avoid calling GetGridTrackSize to find intrinsic sized areas

The GetGridTrackSize function has some particular logic that must be
run only after having set up the algorithm.

The reason is that we consider the relative sized track as 'auto'
during intrinsic size computation. In order to know this, we use the
AvailableSize() function, which is only valid after setting up the
algorithm, where we set the actual available size, if definite, or
nullopt in case of indefinite size.

The bug fixed by this CL is caused by this incorrect use of the
GetGridTrackSize funcion as part of the IsIntrinsicSizedGridArea logic.
Since we compute the baseline offsets before running the track sizing
algorithm, hence before having set it up, we are incorrectly assuming
that relative sized tracks should be managed as 'auto', even during the
layout logic.

In some situations, like the one described in the bug, this lead to
conclude that items of such areas are not participating in the
baseline alignment, hence, we don't compute  the baselines context for
them.

When we execute the alignment logic and retrieve the baseline offsets,
as this happens after the track sizing algorithm has been run, we
handle such relative sized tracks with their actual size. This items
can now participating in baseline alignment (no cyclic dependency), but
there is no computed baseline context for such items.

Bug:  847839 
Change-Id: I157d288911dd47754cf3b4daf583fe6400559743
Reviewed-on: https://chromium-review.googlesource.com/1085910
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Manuel Rego Casasnovas <rego@igalia.com>
Cr-Commit-Position: refs/heads/master@{#564462}
[add] https://crrev.com/e77783c0213b9e81c2cebbd7c52e09e4c8a5d6e1/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-self-baseline-and-relative-sized-tracks-crash-expected.txt
[add] https://crrev.com/e77783c0213b9e81c2cebbd7c52e09e4c8a5d6e1/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-self-baseline-and-relative-sized-tracks-crash.html
[modify] https://crrev.com/e77783c0213b9e81c2cebbd7c52e09e4c8a5d6e1/third_party/blink/renderer/core/layout/grid_track_sizing_algorithm.cc
[modify] https://crrev.com/e77783c0213b9e81c2cebbd7c52e09e4c8a5d6e1/third_party/blink/renderer/core/layout/grid_track_sizing_algorithm.h

This issue should be FIXED now.

ClusterFuzz has detected this issue as fixed in range 564461:564462.

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

Fuzzer: inferno_twister
Job Type: linux_ubsan_chrome
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  begin
  blink::BaselineContext::FindCompatibleSharedGroup
  GetSharedGroup
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=562405:562407
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=564461:564462

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

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 6270785065582592 is verified as fixed, so closing issue as verified.

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

ClusterFuzz testcase 6009305678217216 is still reproducing on tip-of-tree build (trunk).

Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.

The issue in testcase 6009305678217216 is a different one, already reported in  bug #850510 . I think we can keep this one as closed.