Closed
Bug 1063194
Opened 10 years ago
Closed 10 years ago
Assertion failure in Axis::OverscrollBy(): GetCompositionEnd() != GetPageEnd()
Categories
(Core :: Panning and Zooming, defect)
Tracking
()
RESOLVED
FIXED
mozilla35
People
(Reporter: botond, Assigned: botond)
Details
Attachments
(3 files)
:khuey reported running into this [1] while scrolling the SMS app, but wasn't able to repro it.
We should log the values of GetCompositionEnd() and GetPageEnd() to better understand why the assertion is failing - are we really at the end of the page and our COORDINATE_EPSILON is just too small, or is there a logic error somewhere and we are getting here when we're not at the end of the page?
[1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/Axis.cpp?rev=b54f8eca9cb9#122
Assignee | ||
Comment 3•10 years ago
|
||
I had to change MOZ_ASSERT to NS_ASSERTION because MOZ_ASSERT requires a string literal, while we want to print the values of some variables in the assertion message.
I then had to add MOZ_CRASH because NS_ASSERTION doesn't crash.
Assignee: nobody → botond
Attachment #8484615 -
Flags: review?(bugmail.mozilla)
Comment 4•10 years ago
|
||
Comment on attachment 8484615 [details] [diff] [review]
Make the assertions more informative
Review of attachment 8484615 [details] [diff] [review]:
-----------------------------------------------------------------
I'm not sure that this will give you enough information to actually fix the problem though.
Attachment #8484615 -
Flags: review?(bugmail.mozilla) → review+
Assignee | ||
Comment 5•10 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4)
> I'm not sure that this will give you enough information to actually fix the
> problem though.
Do you have any suggestions for other information we could log that might?
Assignee | ||
Comment 6•10 years ago
|
||
landing |
Comment 7•10 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #5)
> Do you have any suggestions for other information we could log that might?
Hm, not in particular. I think if we had gdb attached at the crash point it would probably give us everything we need, but it's probably too much to log all of the APZ state. I just worry that this debug code will sit there forever :/
Comment 8•10 years ago
|
||
Assignee | ||
Comment 9•10 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #7)
> (In reply to Botond Ballo [:botond] from comment #5)
> > Do you have any suggestions for other information we could log that might?
>
> Hm, not in particular. I think if we had gdb attached at the crash point it
> would probably give us everything we need, but it's probably too much to log
> all of the APZ state. I just worry that this debug code will sit there
> forever :/
Bugzilla should have a feature where we can ask it to needinfo us on a bug after a certain period of time :) (so e.g. in this case I could get it to needinfo me in a month to remove the debug code if it hasn't proved useful).
That said, if someone does run into this assertion again, I believe the numbers added here do give some useful information: if the two values are close but not quite close enough, we know we (very likely) need to look at increasing COORDINATE_EPSILON; otherwise, we know there is some flaw in our logic (or memory corruption / thread safety violation / something else that violates basic assumptions) that we need to track down.
Assignee | ||
Comment 10•10 years ago
|
||
(In reply to Cameron McCormack (:heycam) from comment #8)
> Bustage fix:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/4b9b28b4a92a
Thanks! (And sorry for the bustage :/).
Comment 11•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/d3587c227172
https://hg.mozilla.org/mozilla-central/rev/4b9b28b4a92a
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
You need to log in
before you can comment on or make changes to this bug.
Description
•