Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Attempted to subtract [n - nscoord_MAX]), at src/obj-firefox/dist/include/nsCoord.h:208
Categories
(Core :: Layout, defect, P3)
Tracking
()
People
(Reporter: tsmith, Assigned: MatsPalmgren_bugz)
References
(Blocks 1 open bug)
Details
(Keywords: assertion, testcase)
Attachments
(2 files)
Updated•6 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 1•4 years ago
|
||
A Pernosco session is available here: https://pernos.co/debug/b0BlKgsTK6AG8qBAnFG0cA/index.html
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
InlinePrefISizeData::ForceBreak does:
NSCoordSaturatingSubtract(mCurrentLine, mTrailingWhitespace, nscoord_MAX);
mTrailingWhitespace is nscoord_MAX and came from:
https://searchfox.org/mozilla-central/rev/a8773ba2a8f015e0525f219a7e55087b04d30258/layout/generic/nsTextFrame.cpp#8476
(the testcase has word-spacing:15946245.3ch
)
I tend to think we should simply remove this assertion...
Assignee | ||
Comment 3•4 years ago
|
||
Comment 6•4 years ago
|
||
I'm a bit sad to lose this assertion, as it was capable of pointing out genuine issues - as it happens, it just showed up in bug 1710116, where it was the result of failure to appropriately use saturating addition earlier in the code. That resulted in values greater than nscoord_MAX, which isn't likely to end well... this assertion was the canary that let us know things were broken.
Assignee | ||
Comment 7•4 years ago
|
||
I disagree that bug 1710116 is a "genuine issue". It's a synthetic testcase using inline-size: 3579845520.820976vw
which will never occur on any real web sites.
There are two ways to go about nscoord
overflow that I think are reasonable:
A. Make nscoord
a class type with overloaded arithmetic operators that systematically checks for overflow. I.e. make nscoord
behave as a saturated integer type.
-or-
B. Don't try to prevent integer overflow anywhere, but add std::max(0, value)
in a few strategic places where a positive value is expected, such as the result of calculating an intrinsic size or whatnot.
I firmly believe that B is the right choice. It just doesn't matter what the layout result is when nonsensical values like inline-size: 3579845520.820976vw
are used. Take for example BasicTableLayoutStrategy::DistributeISizeToColumns
- in this function we should simply remove all the NSCoordSaturatingAdd
calls and then we can do a std::max(0, result)
at the end (if we feel it's worth it). I just don't think that the performance penalty for doing A is worth it to handle these synthetic testcases.
And I don't think that sprinkling NSCoordSaturatingAdd
calls in mostly random places is a reasonable solution.
Comment 8•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Updated•4 years ago
|
Description
•