588591 - Crash in [@ nsIFrame::GetOffsetToCrossDoc(nsIFrame const*) ] due to plugin calling script during painting

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Marcia Knous [:marcia]]

Seen while running  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4) Gecko/20100818 Firefox/4.0b4

STR:
1. Load Facebook and search for the game "Wild Ones"
2. The first time the game launches I crash in this stack. http://crash-stats.mozilla.com/report/index/d8f29cae-d4a0-40ba-98d9-2222e2100818 is my report.

There are crashes showing up in early beta data as well, but I am not able to repro this using the Mac build.

Frame  	Module  	Signature [Expand]  	Source
0 	xul.dll 	nsIFrame::GetOffsetToCrossDoc 	layout/generic/nsFrame.cpp:3549
1 	xul.dll 	nsDisplayImage::Paint 	layout/generic/nsImageFrame.cpp:1156
2 	xul.dll 	mozilla::FrameLayerBuilder::DrawThebesLayer 	layout/base/FrameLayerBuilder.cpp:1436
3 	xul.dll 	mozilla::layers::BasicThebesLayer::PaintBuffer 	gfx/layers/basic/BasicLayers.cpp:329
4 	xul.dll 	mozilla::layers::BasicThebesLayer::Paint 	gfx/layers/basic/BasicLayers.cpp:410
5 	xul.dll 	mozilla::layers::BasicLayerManager::PaintLayer 	gfx/layers/basic/BasicLayers.cpp:1058
6 	xul.dll 	mozilla::layers::BasicLayerManager::PaintLayer 	gfx/layers/basic/BasicLayers.cpp:1066
7 	xul.dll 	mozilla::layers::BasicLayerManager::EndTransaction 	gfx/layers/basic/BasicLayers.cpp:966
8 	xul.dll 	nsDisplayList::PaintForFrame 	layout/base/nsDisplayList.cpp:395
9 	xul.dll 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1406
10 	xul.dll 	PresShell::Paint 	layout/base/nsPresShell.cpp:5934
11 	xul.dll 	nsViewManager::RenderViews 	view/src/nsViewManager.cpp:459
12 	xul.dll 	nsViewManager::Refresh 	view/src/nsViewManager.cpp:425
13 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:912
14 	xul.dll 	HandleEvent 	view/src/nsView.cpp:160
15 	xul.dll 	nsWindow::DispatchEvent 	widget/src/windows/nsWindow.cpp:3458
16 	xul.dll 	nsWindow::DispatchWindowEvent 	widget/src/windows/nsWindow.cpp:3486
17 	xul.dll 	nsWindow::OnPaint 	widget/src/windows/nsWindowGfx.cpp:563
18 	xul.dll 	nsWindow::ProcessMessage 	widget/src/windows/nsWindow.cpp:4661
19 	xul.dll 	nsWindow::WindowProcInternal 	widget/src/windows/nsWindow.cpp:4251
20 	xul.dll 	nsWindow::WindowProc 	widget/src/windows/nsWindow.cpp:4206
21 	user32.dll 	InternalCallWinProc 	
22 	user32.dll 	NtUserGetDC 	
23 	user32.dll 	DispatchClientMessage 	
24 	user32.dll 	__fnDWORD 	
25 	ntdll.dll 	ntdll.dll@0x100e5 	
26 	xul.dll 	nsWindow::DispatchStarvedPaints 	widget/src/windows/nsWindow.cpp:3595
27 	user32.dll 	InternalEnumWindows 	
28 	user32.dll 	EnumChildWindows 	
29 	xul.dll 	nsWindow::DispatchPendingEvents 	widget/src/windows/nsWindow.cpp:3630
30 	xul.dll 	nsWindow::ProcessMessage 	widget/src/windows/nsWindow.cpp:4734
31 	xul.dll 	nsWindow::WindowProcInternal 	widget/src/windows/nsWindow.cpp:4251
32 	xul.dll 	nsWindow::WindowProc 	widget/src/windows/nsWindow.cpp:4206
33 	user32.dll 	InternalCallWinProc 	
34 	user32.dll 	UserCallWinProcCheckWow 	
35 	user32.dll 	DispatchMessageWorker 	
36 	user32.dll 	DispatchMessageW 	
37 	xul.dll 	nsAppShell::ProcessNextNativeEvent 	widget/src/windows/nsAppShell.cpp:286
38 	xul.dll 	nsBaseAppShell::OnProcessNextEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:300
39 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:517
40 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:118
41 	xul.dll 	xul.dll@0xb7a45b 	
42 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
43 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
44 	xul.dll 	SearchTable 	obj-firefox/xpcom/build/pldhash.c:439
45 	xul.dll 	_SEH_epilog4

Comment 1

[Marcia Knous [:marcia]]

I cannot always trigger the crash, but it seems to happen more consistently when I launch the game from the menu link on the right hand side of the Facebook maine page.

Comment 2

[Martijn Wargers (dead)]

Robert would probably know something about this type of crash.

Comment 3

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

Can you trigger it in a debug build?

Comment 4

[Martijn Wargers (dead)]

Attachment: assertions and stacks of them

I didn't crash in a debug build, but I did see 2 different assertions (multiple times):
###!!! ASSERTION: This is unsafe! Fix the caller!: 'Error', file c:/mozilla-buil
d/mozilla-central/content/events/src/nsEventDispatcher.cpp, line 514

###!!! ASSERTION: Want to fire mutation events, but it's not safe: '(aNode->IsNo
deOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aNode)-> IsInNativeAnony
mousSubtree()) || sScriptBlockerCount == sRemovableScriptBlockerCount', file c:/
mozilla-build/mozilla-central/content/base/src/nsContentUtils.cpp, line 3620

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

So plugin calling JS at wrong time.
We should just kill the plugin if that happens.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

I thought we have a bug open for this, but maybe not.

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Bug 552512 might be what you're thinking of.

The minidump in comment 0 seems to implicate flash.  Is that what this game is implemented with?

Regardless, that settles it.  We've been fearing this case but to my knowledge haven't seen it happen in the field.  Totally agree with comment 5, we should just nuke plugin subprocesses that do this.  (Dunno how to deal with in-process plugins that do the same thing ...)

Comment 8

[Martijn Wargers (dead)]

(In reply to comment #5)
> So plugin calling JS at wrong time.
> We should just kill the plugin if that happens.

But doesn't that mean, the user can't play the game anymore?

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to comment #8)
> (In reply to comment #5)
> > So plugin calling JS at wrong time.
> > We should just kill the plugin if that happens.
> 
> But doesn't that mean, the user can't play the game anymore?

Yes, but if this happens, the game is causing the firefox process to enter a state where the firefox process would likely crash.  We'd rather kill the plugin process than have firefox crash.

Comment 10

[Martijn Wargers (dead)]

Is there a solution possible that involves no crashing at all?

Comment 11

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

Bug 556487, asynchronous plugin rendering.

Comment 12

[Benjamin Smedberg]

It happens *all the time* in the field with silverlight. When I turn off npruntime while painting, most windowless silverlight on the web stops working.

I think we should just dup this to bug 552512 and get async rendering landed.

Comment 14

[Benjamin Smedberg]

chofmann says that this is the #2 topcrash, and we know that plugins don't crash this regularly.

From the stack, we're calling      xul.dll!mozilla::plugins::PluginInstanceParent::NPP_HandleEvent(void * event=0x002cb8bc)  Line 802 + 0x10 bytes    C++

during painting, which doesn't win RPC races.

This is *probably* a duplicate of bug 583053.

Comment 15

[Marcia Knous [:marcia]]

I can no longer reproduce this on XP, Vista or 7 using Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100920 Firefox/4.0b7pre and using steps in Comment 0.

Moreover, crash stats does not seem to show any new crashes in this signature since the 2010081800 build, which was 4.0b4.

Comment 16

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

Yay! Probably mitigated by bug 594774. Will be fixed for real when bug 556487 is extended for Windows. bsmedberg, do we have a bug for that?

Comment 17

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

Although if it was fixed in August, it wasn't bug 594774 that mitigated it.

Comment 18

[LegNeato]

As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)