1349171 - Intermittent test_navigation.py TestBackForwardNavigation.test_frameset_after_navigating_in_frame | application crashed [@ nsIFrame::GetOffsetTo(nsIFrame const *)]

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect)

Description

[Treeherder Bug Filer]

Filed by: cbook [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=85221476&repo=mozilla-inbound

https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win64-pgo/1490060203/mozilla-inbound_win8_64_test_pgo-marionette-e10s-bm119-tests1-windows-build110.txt.gz

Comment 1

[Carsten Book [:Tomcat]]

Attachment: crash stack

Comment 2

[Carsten Book [:Tomcat]]

jet, do you know who could take look at this crash, thanks ?

Comment 3

[Jet Villegas (inactive)]

Logs indicate it crashes here:
http://searchfox.org/mozilla-central/source/layout/generic/nsFrame.cpp#6026

...from this call:
http://searchfox.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp#3100

Timothy: can you see how we might get into this state with the scrollbar parts? (Note the test is going back/forward in navigation history.)

Comment 4

[Timothy Nikkel (:tnikkel)]

scrollParts[i] will be a direct child of mOuter. So in GetOffsetTo we first walk from mOuter to the root frame, calling GetPosition on each frame. Then we walk from scrollParts[i] to the root frame, calling get position on each frame. So the only pointer that could be bad is the parent pointer on scrollParts[i]. This doesn't seem too likely because the scrollParts is managed by the scrollframe, and the code isn't that complex and we haven't seen any other problems with it that I know of.

Looks like this has happened only once so far

https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1349171&startday=2017-02-06&endday=2017-03-23&tree=all

So my inclination is to see if this happens more before putting further effort into investigating.