Since r281439 the test fast/box-shadow/box-shadow-huge-area-crash.html fails on GTK the 99% of the times and the other 1% it crashes. On WPE it passes fine.
This is the diff for when it fails https://people.igalia.com/clopez/wkbug/229740/layout-test-results/results.html I don't have info for when it crashes. On the gtk-release bot it crashed 2 times since r281439 but no backtraces were generated. See https://build.webkit.org/#/builders/57/builds/3420 and https://build.webkit.org/#/builders/57/builds/3395 On the GTK debug bot it has not crashed so far and I have been unable to make it crash locally.
Expectations updated on r281824
(In reply to Carlos Alberto Lopez Perez from comment #0) > Since r281439 the test fast/box-shadow/box-shadow-huge-area-crash.html fails > on GTK the 99% of the times and the other 1% it crashes. > > On WPE it passes fine. This is weird, because the change in r281439 is the same for GTK and WPE ports...
OK, I think I figured this one out. The cause of this issue is `hb_position_t` aka `int32_t`. This type is used to represent advances and offset of a glyph in `hb_buffer`. Its format is 16.16, i.e. 16 bits for the integer part and 16 bits for the fractional precision part. See https://github.com/harfbuzz/harfbuzz/issues/2714 for details. But it is *singed* and the first bit is the sign bit. That means the maximum advance and offset value is 2^15 and not 2^16. This limits the maximum advance and offset value to `std::numeric_limits<short>::max()` i.e 32767. We use HarfBuzz to measure text size only when the complex text code path is taken. Until 259842@main WPE port used the simple code path when possible. This explains why the issue was reproducible only on GTK port. PR is coming :)
Pull request: https://github.com/WebKit/WebKit/pull/10583
Committed 260882@main (1516848f1a90): <https://commits.webkit.org/260882@main> Reviewed commits have been landed. Closing PR #10583 and removing active labels.