Closed Bug 526592 Opened 11 years ago Closed 7 years ago

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


(Core :: Layout, defect)

Not set





(Reporter: chofmann, Unassigned)


(Blocks 1 open bug)


(Keywords: crash)

Crash Data

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
Flags: blocking1.9.2?
Flags: blocking1.9.2? → wanted1.9.2+
Whiteboard: [sg:investigate]
most of the stacks look like

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
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().
There are also a lot of crashes in the search that are *not* this signature, but are instead coming from nsDisplayOpacity::Paint: e.g.

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.
> 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?
shows  nsStyleContext::GetStyleDisplay() as the #3 top fp crash.
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?
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.
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?
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.
Group: core-security
Whiteboard: [sg:investigate]
dbaron / zack, here's how you can reproduce this crash:


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()
Crash Signature: [@ nsStyleContext::GetStyleDisplay() ]
nothing in crash-stats for this sig (or substring of sig) in past month for current versions.  (all version 19 or older)
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.