526592 - Firefox 3.6b1 Crash [@ nsStyleContext::GetStyleDisplay() ] w/ addresses 0xfffffffffffde '*' and others?

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[chris hofmann]

new crashes with signatures nsStyleContext::GetStyleDisplay() and addresses like 0xfffffffff0dea81f 0xfffffffffffdef09 and maybe others have started appearing in the 3.6b1 crash data and appear to be exposed as the result of turning on frame poisoning.

see bug 526587 for more details

current crash list at

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6b1&query_search=signature&query_type=exact&query=nsStyleContext%3A%3AGetStyleDisplay%28%29&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsStyleContext%3A%3AGetStyleDisplay%28%29

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can we get any URLs here?

Comment 4

[chris hofmann]

most of the stacks look like
http://crash-stats.mozilla.com/report/index/098c29ef-6d68-430d-a5bf-9983d2091103

Frame  	Module  	Signature [Expand]  	Source
0 	xul.dll 	nsIFrame::GetStyleDisplay 	layout/style/nsStyleStructList.h:95
1 	xul.dll 	xul.dll@0x42ad18 	
2 	xul.dll 	PresShell::HandleEventInternal 	layout/base/nsPresShell.cpp:6451
3 	xul.dll 	PresShell::HandlePositionedEvent 	layout/base/nsPresShell.cpp:6288
4 	xul.dll 	PresShell::HandleEvent 	layout/base/nsPresShell.cpp:6152
5 	xul.dll 	nsViewManager::HandleEvent 	view/src/nsViewManager.cpp:1224
6 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:1203
7 	xul.dll 	HandleEvent 	view/src/nsView.cpp:167
8 	xul.dll 	nsWindow::DispatchEvent 	widget/src/windows/nsWindow.cpp:2830
9 	xul.dll 	nsWindow::DispatchWindowEvent 	widget/src/windows/nsWindow.cpp:2858
10 	xul.dll 	nsWindow::DispatchMouseEvent 	widget/src/windows/nsWindow.cpp:3233
11 	xul.dll 	ChildWindow::DispatchMouseEvent 	widget/src/windows/nsWindow.cpp:6834

Comment 5

[Zack Weinberg (:zwol)]

The frame with no function name is almost certainly an nsIEventManager::PostHandleEvent() implementation.  Called like so...

Olli@8236  6449        rv = manager->PostHandleEvent(mPresContext, aEvent,
Olli@8292  6450                                      GetCurrentEventFrame(), aStatus,
Olli@8292  6451                                      weakView.GetView());

and nsPresShell::GetCurrentEventFrame, guess what, calls GetPrimaryFrameFor().

Comment 6

[Zack Weinberg (:zwol)]

There are also a lot of crashes in the search that are *not* this signature, but are instead coming from nsDisplayOpacity::Paint: e.g. http://crash-stats.mozilla.com/report/index/15f637f4-bda5-4c01-9101-22fbb2091117

0	xul.dll	nsStyleContext::GetStyleDisplay	layout/style/nsStyleStructList.h:95
1	xul.dll	nsDisplayOpacity::Paint	layout/base/nsDisplayList.cpp:987
2	xul.dll	nsDisplayList::Paint	layout/base/nsDisplayList.cpp:385
3	xul.dll	nsDisplayClip::Paint	layout/base/nsDisplayList.cpp:1076
4	xul.dll	nsDisplayList::Paint	layout/base/nsDisplayList.cpp:385
5	xul.dll	nsDisplayClip::Paint	layout/base/nsDisplayList.cpp:1076
6	xul.dll	nsDisplayList::Paint	layout/base/nsDisplayList.cpp:385
7	xul.dll	nsDisplayClip::Paint	layout/base/nsDisplayList.cpp:1076
8	xul.dll	nsDisplayList::Paint	layout/base/nsDisplayList.cpp:385
9	xul.dll	nsDisplayClip::Paint	layout/base/nsDisplayList.cpp:1076
10	xul.dll	nsLayoutUtils::PaintFrame	layout/base/nsLayoutUtils.cpp:1132
11	xul.dll	PresShell::Paint	layout/base/nsPresShell.cpp:5794
12	xul.dll	nsViewManager::RenderViews	view/src/nsViewManager.cpp:534
13	xul.dll	nsViewManager::Refresh	view/src/nsViewManager.cpp:493

This is is the "redraw an entire view" code path, it's walking the frame tree from a view's ClientData pointer.  GetPrimaryFrameFor does not appear to be involved.

Comment 7

[chris hofmann]

> There are also a lot of crashes in the search that are *not* this signature

is there a socorro skip list change, or other way to sort out or group this set of signatures better?

https://bug526587.bugzilla.mozilla.org/attachment.cgi?id=414317&t=ytKa49fedH
shows  nsStyleContext::GetStyleDisplay() as the #3 top fp crash.

Comment 8

[Zack Weinberg (:zwol)]

nsIFrame::GetStyle* and nsStyleContext::GetStyle* are not exactly straightforward accessor functions.  They are typesafe wrappers around nsStyleContext::GetStyleData, which does quite a bit of work.  dbaron, do you think the problem here is more likely to be with the style tree itself, or is this still a frame tree issue?

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Most likely a frame tree issue, since the code to manage object lifetimes in the style tree (style contexts and rule nodes) is much simpler.

It seems reasonable to expect this sort of crash if |this| to nsStyleContext::GetStyleDisplay was 0xfffff0de... due to that being the mStyleContext of a destroyed frame.  I didn't check that that's actually what's happening, but it seems the most likely.

Comment 10

[Zack Weinberg (:zwol)]

That makes sense to me, too.  Do you think a skiplist change to merge nsStyleContext::GetStyle* and nsIFrame::GetStyle* with their callers is a good idea, then?

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Probably... except I'd be a little concerned since a bunch of the stacks look corrupted (hopefully just a bug in the breakpad stackwalker) between that function and its caller.

Comment 12

[Seth Spitzer]

dbaron / zack, here's how you can reproduce this crash:

see http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp#2238

in nsTreeBodyFrame::GetImageSize(), add this call to ClearStyleAndImageCaches()

  GetImage(aRowIndex, aCol, aUseContext, aStyleContext, useImageRegion, getter_AddRefs(image));
+ ClearStyleAndImageCaches();
  const nsStylePosition* myPosition = styleContext->GetStylePosition();

nsTreeBodyFrame owns mStyleCache.  mStyleCache owns mCache.

ClearStyleAndImageCaches() calls mStyleCache.Clear() which deletes mCache.

What I don't know yet is how the call to ClearStyleAndImageCaches() / mStyleCache.Clear() happens in the wild as result of a call to GetImage(), or if something else calls ClearStyleAndImageCaches() or nsTreeBodyFrame::DidSetStyleContext(), which also calls mStyleCache.Clear()

Comment 13

[Wayne Mery (:wsmwk)]

nothing in crash-stats for this sig (or substring of sig) in past month for current versions.  (all version 19 or older)