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

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.

Robert would probably know something about this type of crash.

Can you trigger it in a debug build?

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

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

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

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 ...)

(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?

(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.

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

Bug 556487, asynchronous plugin rendering.

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.

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.

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.

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?

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

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)