Closed Bug 1063194 Opened 10 years ago Closed 10 years ago

Assertion failure in Axis::OverscrollBy(): GetCompositionEnd() != GetPageEnd()

Categories

(Core :: Panning and Zooming, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

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
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 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+
(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?
(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 :/
(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.
(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 :/).
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.

Attachment

General

Created:
Updated:
Size: