Open Bug 1608305 Opened 5 years ago Updated 2 years ago

Crashtest's assertion count might be associated with a wrong test run

Categories

(Testing :: Reftest, defect, P3)

Version 3
defect

Tracking

(Not tracked)

People

(Reporter: TYLin, Unassigned)

References

Details

Attachments

(1 file)

When I was looking at bug 1607658, I notice that if gecko produces a lot of assertions, the assertion print might be buffered and being associated with the next test run.

Specifically, I was looking at two adjacent tests 1015844.html and 1032450.html. [1]

The first test 1015844.html has multi-column layout, so it can generated assertions like

ASSERTION: Available block-size should be constrained because it's restricted by the computed block-size when our reflow input is created in nsBlockFrame::ReflowBlockFrame()! [2]

However, the second test 1032450.html has no multi-column layout. There is no way that it can generated such assertions.

But in the attached partial log [3], many assertions are printed after the second test 1032450.html starts running. This doesn't seem to be reasonable to me.

[1] https://searchfox.org/mozilla-central/rev/ba4fab1cc2f1c9c4e07cdb71542b8d441707c577/layout/generic/crashtests/crashtests.list#576-577
[2] https://searchfox.org/mozilla-central/rev/ba4fab1cc2f1c9c4e07cdb71542b8d441707c577/layout/generic/nsColumnSetFrame.cpp#934-936
[2] Copied from the original log in https://firefoxci.taskcluster-artifacts.net/P69HXJE6QfKKszgW0ErALQ/0/public/test_info//logcat-emulator-5554.log

The priority flag is not set for this bug.
:ahal, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(ahal)
Flags: needinfo?(ahal)
Priority: -- → P3
Regressed by: 1607658
Blocks: 1607658
No longer regressed by: 1607658
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: