Closed Bug 1190936 Opened 9 years ago Closed 9 years ago

crash in nsLayoutUtils::CalculateAndSetDisplayPortMargins(nsIScrollableFrame*, nsLayoutUtils::RepaintMode)

Categories

(Core :: Panning and Zooming, defect)

42 Branch
Unspecified
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
firefox42 --- fixed

People

(Reporter: tracy, Assigned: kats)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is report bp-bdfd2418-c9e9-494b-9603-65b5b2150803. ============================================================= This is a startup crash that has made it's way into top 3 by volume on Nightly 42 at 202 crashes in the past week.
Comment 0's crash report looks like a null-deref crash (crash address 0x18), because |frame| is null at this line of nsLayoutUtils::CalculateAndSetDisplayPortMargins: http://hg.mozilla.org/mozilla-central/annotate/32712cd01159/layout/base/nsLayoutUtils.cpp#l2982 ...which I think means the passed-in aScrollFrame was either null or not a scroll frame. kats & botond, you guys have hg blame for stack frames 0 and 1 here (respectively), so I suspect you might be best-equipped to theorize about / investigate this.
Flags: needinfo?(bugmail.mozilla)
Component: Layout → Panning and Zooming
Hm. Tracing backwards through the code it means that at [1] the condition "guidIsValid && !nsLayoutUtils::GetDisplayPort(dpElement, nullptr)" was true. Combined with scrollAncestor being null, this means that the root document element for the widget existed but didn't have a displayport. I think we rely on the root document element getting a displayport from when we first create the ChromeProcessController, but in this scenario it looks like either that failed or the document element was changed since that happened. The latter may be a result of an add-on. I looked at a handful of the reports and all the ones I looked have this extension in common: {972ce4c6-7e08-4474-a285-3208198ce6fd} so that might be related. [1] http://hg.mozilla.org/mozilla-central/annotate/32712cd01159/gfx/layers/apz/util/APZCCallbackHelper.cpp#l629
Flags: needinfo?(bugmail.mozilla)
Assignee: nobody → bugmail.mozilla
.. or maybe that's unrelated, since it appears to just be a placeholder for the default theme and doesn't contain any code or anything. http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/extensions/%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D/
Attached patch Band-aidSplinter Review
Without STR it's hard to diagnose and fix this properly, but we should at least stop the crashes.
Attachment #8643251 - Flags: review?(botond)
If it means anything, one of the comments says: Dragging a window/tab back onto the main one.
Thanks, that might be useful. I tried a bunch of scenarios dragging tabs around between windows and wasn't able to repro the crash though :(
Attachment #8643251 - Flags: review?(botond) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: