Assertion failure: aStatus.IsEmpty() (Caller should pass a fresh reflow status!) in [@ nsBlockFrame::Reflow]
Categories
(Core :: Layout, defect, P4)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr52 | --- | unaffected |
| firefox-esr60 | --- | wontfix |
| firefox-esr78 | --- | wontfix |
| firefox-esr115 | --- | wontfix |
| firefox56 | --- | wontfix |
| firefox57 | --- | wontfix |
| firefox58 | --- | wontfix |
| firefox59 | --- | wontfix |
| firefox63 | --- | wontfix |
| firefox64 | --- | wontfix |
| firefox65 | --- | wontfix |
| firefox86 | --- | wontfix |
| firefox87 | --- | wontfix |
| firefox88 | --- | wontfix |
| firefox125 | --- | wontfix |
| firefox126 | --- | verified |
| firefox127 | --- | verified |
People
(Reporter: tsmith, Assigned: dholbert)
References
(Blocks 1 open bug)
Details
(Keywords: assertion, regression, testcase)
Crash Data
Attachments
(3 files)
Comment 1•8 years ago
|
||
Comment 2•8 years ago
|
||
Comment 3•8 years ago
|
||
Comment 4•8 years ago
|
||
| Reporter | ||
Updated•7 years ago
|
| Reporter | ||
Comment 5•5 years ago
|
||
A Pernosco session is available here: https://pernos.co/debug/OiRcg7tFnTb9VFNIRJ0STQ/index.html
Updated•5 years ago
|
Updated•3 years ago
|
| Assignee | ||
Comment 6•2 years ago
|
||
I don't hit the fatal assertion with this bug's testcase in a current debug build, though I do hit several copies of this non-fatal assertion:
###!!! ASSERTION: overflow containers must be zero-block-size: 'finalSize.BSize(wm) == 0',
file layout/generic/nsBlockFrame.cpp:2292
I do trip this assertion if I load bug 1881375's testcase in a debug build, though. (That bug's testcase triggers a null-deref in opt builds, but it makes debug builds trip this fatal assertion first.)
I think the assertion is pointing us at a legitimate problem: nsGridContainerFrame has one spot where it reflows a child and passes in its own ReflowStatus flag:
https://searchfox.org/mozilla-central/rev/f602853ba8d55ba157e2a74d9b571615f6ed97b8/layout/generic/nsGridContainerFrame.cpp#8832-8833
ReflowInFlowChild(child, info, aContainerSize, Nothing(), nullptr, aState,
aContentArea, aDesiredSize, aStatus);
We should probably be declaring a distinct childStatus there for each child, like we do in other calls to ReflowInFlowChild in this file.
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 7•2 years ago
|
||
This matches what we do in flexbox, here:
https://searchfox.org/mozilla-central/source/layout/generic/nsFlexContainerFrame.cpp#2024,2033-2035,2038-2042
We have fuzzer testcases where the child reflow sets the reflow status to
"OverflowIncomplete", which is fine from the perspective of the
immediately-following "IsComplete()" assertion in the contextual code of this
patch; but it's not fine if we then go on to reuse that
already-set-to-OverflowIncomplete status for another child's reflow.
Updated•2 years ago
|
Comment 9•2 years ago
|
||
| bugherder | ||
Comment 11•2 years ago
|
||
Copying crash signatures from duplicate bugs.
Updated•2 years ago
|
Comment 12•2 years ago
|
||
The patch landed in nightly and beta is affected.
:dholbert, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox126towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Comment 13•2 years ago
|
||
This matches what we do in flexbox, here:
https://searchfox.org/mozilla-central/rev/8c3ca2f5a74e0ba59c3d9dddf5468a2ffab13467/layout/generic/nsFlexContainerFrame.cpp#2024,2033-2035,2038-2042
We have fuzzer testcases where the child reflow sets the reflow status to
"OverflowIncomplete", which is fine from the perspective of the
immediately-following "IsComplete()" assertion in the contextual code of this
patch; but it's not fine if we then go on to reuse that
already-set-to-OverflowIncomplete status for another child's reflow.
Original Revision: https://phabricator.services.mozilla.com/D207094
Updated•2 years ago
|
Comment 14•2 years ago
|
||
beta Uplift Approval Request
- User impact if declined: crashes
- Code covered by automated testing: yes
- Fix verified in Nightly: yes
- Needs manual QE test: yes
- Steps to reproduce for manual QE testing: Load testcase in bug 1881375, see if you crash.
- Risk associated with taking this patch: Low
- Explanation of risk level: Very targeted patch, which is a step in the direction of correctness/consistency, and reducing inadvertent leakage of temporary layout state to influence later pieces of layout.
- String changes made/needed: None
- Is Android affected?: yes
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 15•2 years ago
|
||
| uplift | ||
Comment 16•2 years ago
|
||
Reproduced the issue with Firefox 126.0b4 on Windows 10x64 by loading the test case from bug 1881375 as stated in comment 14. The Firefox tab crashes with this crash ID. As a side note sometimes I have also got this crash ID.
The issue is verified fixed with Firefox 126.0b5 (20240423115600) from comment 21 and 127.0a1 (20240423214125) on Windows 10x64, macOS 12, and Ubuntu 23.10. Loading the test case from bug 1881375 will no longer crash the Firefox tab.
Description
•