Closed Bug 829909 Opened 12 years ago Closed 12 years ago

crash in nsWindow::Enable @ UserCallWinProcCheckWow

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Version:
20 Branch
Platform:
All
Windows 7
Type:
defect

Tracking

(firefox19 unaffected, firefox20+ verified, firefox21 verified)

Status:
VERIFIED FIXED
Milestone:
mozilla21
Tracking Flags:
Tracking Status
firefox19 --- unaffected
firefox20 + verified
firefox21 --- verified

People

(Reporter: scoobidiver, Assigned: bugzilla)

References

Details

(5 keywords)

Crash Data

Attachments

(1 file)

Fix some Plugin Hang UI synchronization problems
7.30 KB, patch
bbondy
: review+
Details | Diff | Splinter Review
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: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d8ca3e1c469e&tochange=20d1a5916ef6 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 Reason EXCEPTION_ACCESS_VIOLATION_WRITE 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/message_loop.cc:208 50 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:182 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: https://crash-stats.mozilla.com/report/list?signature=UserCallWinProcCheckWow
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
tracking-firefox20: ? → +
Keywords: needURLs, steps-wanted
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.
tracking-firefox20: + → ?
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: https://tbpl.mozilla.org/?tree=Try&rev=c6eed5e7125f
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
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
status-firefox21: affected → fixed
Whiteboard: [leave open]
Target Milestone: --- → mozilla21
The fix of bug 828304 has been uplifted to Aurora.
status-firefox20: affected → fixed
(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. https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=UserCallWinProcCheckWow&reason_type=contains&date=02%2F08%2F2013%2015%3A16%3A17&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=UserCallWinProcCheckWow&page=1#reports
Status: RESOLVED → VERIFIED
status-firefox21: fixed → verified
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: