Closed Bug 829909 Opened 10 years ago Closed 10 years ago

crash in nsWindow::Enable @ UserCallWinProcCheckWow


(Core Graveyard :: Plug-ins, defect, P1)

20 Branch
Windows 7


(firefox19 unaffected, firefox20+ verified, firefox21 verified)

Tracking Status
firefox19 --- unaffected
firefox20 + verified
firefox21 --- verified


(Reporter: scoobidiver, Assigned: bugzilla)



(5 keywords)

Crash Data


(1 file)

It's #8 top browser crasher in 21.0a1 and first showed up with that stack trace in 20.0a1/20130106. The regression range is:
I suspect bug 805591.

Signature 	UserCallWinProcCheckWow More Reports Search
UUID	5c5bdb50-39d1-4634-8a61-c3b542130112
Date Processed	2013-01-12 08:47:53
Uptime	829
Install Age	4.9 hours since version was first installed.
Install Time	2013-01-12 03:52:00
Product	Firefox
Version	21.0a1
Build ID	20130111030906
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7600
Build Architecture	x86
Build Architecture Info	AuthenticAMD family 18 model 1 stepping 0
Crash Address	0xffffffffc0000000
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x9648, AdapterSubsysID: 06051025, AdapterDriverVersion: 8.834.1.2000
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x9648
Total Virtual Memory	2147352576
Available Virtual Memory	1532428288
System Memory Use Percentage	46
Available Page File	4626636800
Available Physical Memory	1708900352

Frame 	Module 	Signature 	Source
0 		@0x330030 	
1 	user32.dll 	UserCallWinProcCheckWow 	
2 	user32.dll 	CallWindowProcAorW 	
3 	user32.dll 	CallWindowProcW 	
4 	xul.dll 	mozilla::plugins::PluginInstanceParent::PluginWindowHookProc 	dom/plugins/ipc/PluginInstanceParent.cpp:1862
5 	user32.dll 	InternalCallWinProc 	
6 	user32.dll 	UserCallWinProcCheckWow 	
7 	user32.dll 	CallWindowProcAorW 	
8 	user32.dll 	CallWindowProcW 	
9 	xul.dll 	PluginWndProcInternal 	dom/plugins/base/nsPluginNativeWindowWin.cpp:327
10 	xul.dll 	CallWindowProcCrashProtected 	xpcom/base/nsCrashOnException.cpp:32
11 	xul.dll 	PluginWndProc 	dom/plugins/base/nsPluginNativeWindowWin.cpp:356
12 	user32.dll 	InternalCallWinProc 	
13 	user32.dll 	UserCallWinProcCheckWow 	
14 	user32.dll 	DispatchClientMessage 	
15 	user32.dll 	__fnDWORD 	
16 	ntdll.dll 	KiUserCallbackDispatcher 	
17 	ntdll.dll 	KiUserApcDispatcher 	
18 	xul.dll 	nsWindow::Enable 	widget/windows/nsWindow.cpp:1751
19 	xul.dll 	nsObjectFrame::SetInstanceOwner 	layout/generic/nsObjectFrame.cpp:800
20 	xul.dll 	nsPluginInstanceOwner::SetFrame 	dom/plugins/base/nsPluginInstanceOwner.cpp:3448
21 	xul.dll 	nsObjectLoadingContent::DisconnectFrame 	content/base/src/nsObjectLoadingContent.cpp:990
22 	xul.dll 	nsObjectLoadingContent::StopPluginInstance 	content/base/src/nsObjectLoadingContent.cpp:2532
23 	xul.dll 	nsObjectLoadingContent::NotifyOwnerDocumentActivityChanged 	content/base/src/nsObjectLoadingContent.cpp:812
24 	xul.dll 	NotifyActivityChanged 	content/base/src/nsDocument.cpp:3916
25 	xul.dll 	EnumerateFreezables 	content/base/src/nsDocument.cpp:8425
26 	xul.dll 	nsTHashtable<mozilla::plugins::PluginModuleChild::NPObjectData>::s_EnumStub 	obj-firefox/dist/include/nsTHashtable.h:486
27 	xul.dll 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.cpp:717
28 	xul.dll 	nsTHashtable<nsPtrHashKey<nsIContent> >::EnumerateEntries 	obj-firefox/dist/include/nsTHashtable.h:237
29 	xul.dll 	nsDocument::RemovedFromDocShell 	content/base/src/nsDocument.cpp:7481
30 	xul.dll 	nsDocumentViewer::Close 	layout/base/nsDocumentViewer.cpp:1452
31 	xul.dll 	nsDocShell::SetupNewViewer 	docshell/base/nsDocShell.cpp:8089
32 	xul.dll 	nsDocShell::Embed 	docshell/base/nsDocShell.cpp:6170
33 	xul.dll 	nsDocShell::CreateContentViewer 	docshell/base/nsDocShell.cpp:7901
34 	xul.dll 	nsDSURIContentListener::DoContent 	docshell/base/nsDSURIContentListener.cpp:122
35 	xul.dll 	nsDocumentOpenInfo::TryContentListener 	uriloader/base/nsURILoader.cpp:659
36 	xul.dll 	nsDocumentOpenInfo::DispatchContent 	uriloader/base/nsURILoader.cpp:360
37 	xul.dll 	nsDocumentOpenInfo::OnStartRequest 	uriloader/base/nsURILoader.cpp:252
38 	xul.dll 	mozilla::net::nsHttpChannel::CallOnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:960
39 	xul.dll 	mozilla::net::nsHttpChannel::InitCacheEntry 	netwerk/protocol/http/nsHttpChannel.cpp:3595
40 	xul.dll 	mozilla::net::nsHttpChannel::ProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1391
41 	xul.dll 	nsHttpChannelAuthProvider::Release 	netwerk/protocol/http/nsHttpChannelAuthProvider.cpp:1473
42 	xul.dll 	mozilla::net::nsHttpChannel::ProcessResponse 	netwerk/protocol/http/nsHttpChannel.cpp:1223
43 	xul.dll 	mozilla::net::nsHttpChannel::OnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:4864
44 	xul.dll 	nsInputStreamPump::OnStateStart 	netwerk/base/src/nsInputStreamPump.cpp:417
45 	xul.dll 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:368
46 	xul.dll 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:82
47 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:627
48 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:82
49 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/
50 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/
51 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:163
52 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:232
53 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:288
54 	xul.dll 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3823
55 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3890
56 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:4093

More reports at:
It's #7 top browser crasher in 20.0a2 and #8 in 21.0a1.
Keywords: topcrash
Aaron, can you please help with investigation here as bug 805591 is the suspected bug ?
Assignee: nobody → aklotz
Keywords: qawanted
Unfortunately there's no smoking gun in this call stack. The Plugin Hang UI changes touched mozilla::plugins::PluginModuleParent but did not touch any of the code shown in this stack.

If bug 805591 is indeed the cause, then it has induced some kind of side effect into the rest of the plugin code.

I'm also curious about bug 828034 and whether it is a different symptom of the same problem.
In case it's not clear from the code, this is very likely to be a case where PluginInstanceParent::PluginWindowHookProc is being called on an already-deleted PluginInstanceParent. This is also almost certainly the cause of bug 828034, which regressed in the same timeframe.

The most likely reason is that when a hang occurs and the plugin is destroyed, PluginInstanceParent::ActorDestroy is not being called, or is being called with a `why` other than `AbnormalShutdown`. This means that PluginInstanceParent::UnsubclassPluginWindow is not being called and the wndproc is left stale.
Blocks: 805591
Priority: -- → P1
When the plugin is destroyed, the Plugin Hang UI is posting a CleanupFromTimeout task to the main thread's MessageLoop. CleanupFromTimeout ends up destroying the PluginModuleParent actor and its subtree with AbnormalShutdown as the reason.

I'm wondering if there are events in the message loop that have been enqueued ahead of the CleanupFromTimeout task.
This patch fixes some synchronization problems that could cause spurious events and/or bad data to be sent between parent and child processes. I have no evidence that this is causing the crash, but this patch will either rule itself out as the problem or fix the problem.
Attachment #703157 - Flags: review?(netzen)
Can someone please attach some STR ? Even if they are not always crashing this.

As I know UserCallWinProcCheckWow means that a window procedure registered during the window creation is trying to process a message. It helps a lot if someone can find some STR.
There are only two comments:
"there is a script or something weird that always fails" (translated by Google)
"Everything keeps freezing and then crashes. it usually happens while I'm rendering something on photoshop."
If it happens while using Photoshop, mabye there can be a photoshop dll file that makes UserCallWinProcCheckWow to not work as expected. I'll try some tests and I will be back with results soon.
Attachment #703157 - Flags: review?(netzen) → review+
Try push with this patch:
Keywords: checkin-needed
Whiteboard: [leave open]
I've tried to reproduce the crashes on both latest Nightly and Aurora, with intense stress testing, but without any luck.

I've also tried to lower dom.ipc.plugins.hangUITimeoutSecs so that the Plugin Hang UI triggers more easily, but still no Firefox crash.

My attempts were with multiple tabs and multiple windows, all with Flash content, both on Windows 7 and Windows 8.
The crash hasn't disappeared on Nightly with this patch, it's still happening in recent builds.
I expect the patch that is about to land in bug 828034 to clear this one up as well.
Depends on: 828034
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [leave open]
Target Milestone: --- → mozilla21
The fix of bug 828304 has been uplifted to Aurora.
(In reply to Manuela Muntean [:Manuela] [QA] from comment #18)
> I can see some crash reports with this signature on Socorro, with the date
> 2013-02-01 and 2013-02-06.
This crash signature is shared by many bugs so it's not worrisome as long as it's a low volume.
UserCallWinProcCheckWow can be a signature for all kinds of different things. The particular case is here is fixed.
QA Contact: manuela.muntean
There's one crash in 20.0b1, bp-e00e2eb6-c035-4a2a-b2cb-7334b2130228, but not related to this bug.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0

I've tried to reproduce this issue as in comment 13 with FF 21 beta 7 (Build Id: 20130506154904) on Windows 7, but without any luck.

In Socorro, there are no new crashes with [@ UserCallWinProcCheckWow] signature on Firefox 21 beta builds. Marking firefox 21 flag as verified based on this.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.