ClampAndAlignWithPixels: "ABORT: clamped(): max must be greater than or equal to min"

RESOLVED FIXED in mozilla25

Status

()

Core
Layout
--
critical
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Jesse Ruderman, Assigned: karlt)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs, {assertion, testcase})

Trunk
mozilla25
x86_64
All
assertion, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Created attachment 775298 [details]
testcase

###!!! ABORT: clamped(): max must be greater than or equal to min: 'max >= min', file nsAlgorithm.h, line 66
(Reporter)

Comment 1

4 years ago
Created attachment 775299 [details]
stack+
(Assignee)

Comment 2

4 years ago
The right hand side of the range rect is < left hand side because the left hand side is so large that a 1 CSS pixel width overflows.

The nscoord is large because it comes from CSSIntPoint via NSIntPixelsToAppUnits().

NSFloatPixelsToAppUnits() clamps to nscoord_MIN,MAX.
There is no reason why NSIntPixelsToAppUnits() won't overflow, so the clamping in NSFloatPixelsToAppUnits() suggests that NSIntPixelsToAppUnits() should also clamp if that is the strategy that we want to propagate.
Assignee: nobody → karlt
Depends on: 575011
OS: Mac OS X → All
(Assignee)

Comment 3

4 years ago
Created attachment 780643 [details] [diff] [review]
clamp CSS pixel to nscoord conversion to nscoord_MIN,MAX

Conversion from device pixels seems less likely to need clamping because
Device pixels often have their own limits (surface sizes), so are probably more likely known not to overflow when converted to nscoord.  Conversion from
CSS pixel is more likely to be converting from a document-specified value and
so there are less likely any guarantees on the range.  I've used
NSToCoordRoundWithClamp to make it explicit that clamping is happening.

Clamping/saturating on input may be less efficient than letting things
overflow and picking a random tolerable value where necessary, but will give
results closer to the authors intentions.  It allows an author to use a large
value to get a maximum effect.  I don't know whether xptc would clamp before
truncation to int32, but overflow at 2^31 would be more predictable than
overflow at nscoord limits which depend on zoom.

I think the main advantage of this approach is that it picks a common place
where overflow can occur and deals with that there, hopefully saving Gecko
bug fixers from having to fix some other bugs like this one.
Attachment #780643 - Flags: review?(roc)
(Assignee)

Updated

4 years ago
Attachment #780643 - Attachment description: cssint.clamp → clamp CSS pixel to nscoord conversion to nscoord_MIN,MAX
(Assignee)

Comment 4

4 years ago
https://tbpl.mozilla.org/?tree=Try&rev=1dcc7b27f3b1
Attachment #780643 - Flags: review?(roc) → review+
(Assignee)

Comment 5

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/26b10ebb6140
https://hg.mozilla.org/integration/mozilla-inbound/rev/c04919af1db8
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/26b10ebb6140
https://hg.mozilla.org/mozilla-central/rev/c04919af1db8
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in before you can comment on or make changes to this bug.