1816574 - Hang with multicol and fuzzer testcase

Status: RESOLVED FIXED

(Core :: Layout: Columns, defect)

Description

[Daniel Holbert [:dholbert]]

bug 1756202's assertion-failure has been fixed, but its testcase causes a hang on my linux laptop.

STR:

1. Apply https://phabricator.services.mozilla.com/D169662 and run the crashtest (or view it in a local build)

Or alternately, just visit that bug's testcase ( https://bugzilla.mozilla.org/attachment.cgi?id=9264595 ) in any build, even a Nightly build.

ACTUAL RESULTS:
Content process hang. Seems to be indefinite, though I haven't given it more than 10 seconds or so before closing the tab.

EXPECTED RESULTS:
No hang.

This isn't reproducible everywhere; I can't repro on a different linux PC, and TYLin wasn't yet able to repro either. It does look like the hang reproduced on Try, though only on TSAN builds:
https://treeherder.mozilla.org/jobs?repo=try&revision=774fc65fedda0cbff97d5bdf537222a7fbc43aba

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: output of ColumnSet logging when viewing the testcase in a local build

Here are the results of doing the following on an affected machine, in up-to-date mozilla-central:

MOZ_LOG="ColumnSet:5" ./mach run --headless layout/generic/crashtests/1756202-1.html

(This is just the first 10,000 lines from doing that.)

Comment 2

[Daniel Holbert [:dholbert]]

[editing to complete partially-typed comment]

When we've figured out what's going on here and been able to address the hang, we can probably land https://phabricator.services.mozilla.com/D169662 , the crashtest from bug 1756202 (which will also serve as a regression test for this bug, at least on TSAN or whatever configs seem to repro the hang).

Comment 3

[Daniel Holbert [:dholbert]]

On my laptop where I can reproduce this, I confirmed that this hang is a regression from bug 1809764:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5c2b32e98bede1e87f5243d8a929de67179d9b83&tochange=cdd9f798f751da8996f9ef3820feedaf36c65136

In a Nightly from before that bug's patches, we load the testcase here ~immediately. In a Nightly from after that bug's patches, we hang.

I've captured an rr recording of the hang in a debug build, with ColumnSet logging enabled. Pernosco's processing it right now, and I'll share the link when I've got it.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

:TYLin, since you are the author of the regressor, bug 1809764, could you take a look?

For more information, please visit auto_nag documentation.

Comment 5

[Daniel Holbert [:dholbert]]

Pernosco trace: https://pernos.co/debug/9ISMo6F7qXWyS3IM_Gymzw/index.html

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1809764

Comment 7

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Bug 1816574 - Force fit the content in nested multicol when ReflowConfig::mForceAuto is true.

The testcase was originated from D169662 written by Daniel Holbert.

Note that the crashtest that hangs the browser might not always be reproducible
locally, and only be reproducible on "Linux 18.04 x64 WebRender tsan opt" build
on try.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/48d87582c2a4
Force fit the content in nested multicol when ReflowConfig::mForceAuto is true. r=emilio

Comment 9

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/48d87582c2a4

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Cristina Horotan [:chorotan] from comment #9)

https://hg.mozilla.org/mozilla-central/rev/48d87582c2a4

Credit where credit is due -- I just noticed that hg shows me as the patch-author here, but in fact this was TYLin's patch.

I think the patch got mis-attributed in hg because TYLin probably started off by using my patch from https://phabricator.services.mozilla.com/D169662 (adding a crashtest), and that commit had me as the commit-author in the hg metadata, and that stuck around in the amended and eventually-landed patch.

(Phabricator unfortunately makes it hard to see who's listed as the changeset author -- you have to click the "Commits" section in the "Revision Contents" part of a phabricator page, and then you can see the "real" hg-exposed authorship metadata, which may or may not match the "Authored by ..." attribution that's shown at the top of phabricator. This discrepancy is a bit confusing, but it's useful for cases where the person who writes a patch is actually distinct from the person who shepherds it through the phabricator/review process.)

Comment 11

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

I think the patch got mis-attributed in hg because TYLin probably started off by using my patch from https://phabricator.services.mozilla.com/D169662 (adding a crashtest), and that commit had me as the commit-author in the hg metadata, and that stuck around in the amended and eventually-landed patch.

Yeah, I did use Daniel's patch as a startpoint, and amend my change on top of it.