Closed Bug 814953 Opened 7 years ago Closed 7 years ago

crash in nsWindow::ProcessMessage


(Core :: Widget: Win32, defect, critical)

19 Branch
Windows 7
Not set



Tracking Status
firefox19 + verified
firefox20 --- verified


(Reporter: scoobidiver, Assigned: jimm)


(Blocks 1 open bug)


(Keywords: crash, regression, topcrash, Whiteboard: [startupcrash])

Crash Data


(2 files, 1 obsolete file)

It's a low volume crash but started spiking on startup in 20.0a1/20121120. The regression range for the spike is:
It might be a dupe of bug 805745.

Signature 	@0x0 | nsWindow::ProcessMessage(unsigned int, unsigned int&, long&, long*) More Reports Search
UUID	d49edbb0-10b5-4b3e-b1dc-b951c2121125
Date Processed	2012-11-25 12:01:45
Uptime	11
Last Crash	3.4 hours before submission
Install Age	5.2 hours since version was first installed.
Install Time	2012-11-25 06:50:00
Product	Firefox
Version	20.0a1
Build ID	20121124130632
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	AuthenticAMD family 16 model 6 stepping 3
Crash Address	0x0
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x9712, AdapterSubsysID: 00000000, AdapterDriverVersion: 8.712.0.0
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers+ 
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x9712
Total Virtual Memory	4294836224
Available Virtual Memory	3754811392
System Memory Use Percentage	60
Available Page File	5335687168
Available Physical Memory	1576013824

Frame 	Module 	Signature 	Source
0 		@0x0 	
1 	xul.dll 	nsWindow::ProcessMessage 	widget/windows/nsWindow.cpp:4748
2 	xul.dll 	nsWindow::QueryInterface 	widget/windows/nsWindow.cpp:422
3 	xul.dll 	CallWindowProcCrashProtected 	xpcom/base/nsCrashOnException.cpp:32
4 	xul.dll 	nsWindow::WindowProc 	widget/windows/nsWindow.cpp:4303
5 	user32.dll 	InternalCallWinProc 	
6 	user32.dll 	NtUserGetDC 	
7 	user32.dll 	DispatchClientMessage 	
8 	user32.dll 	__fnDWORD 	
9 	ntdll.dll 	KiUserCallbackDispatcher 	
10 	ntdll.dll 	KiUserApcDispatcher 	
11 	xul.dll 	nsWindow::Show 	widget/windows/nsWindow.cpp:1196
12 	xul.dll 	nsXULWindow::SetVisibility 	xpfe/appshell/src/nsXULWindow.cpp:803
13 	xul.dll 	nsXULWindow::OnChromeLoaded 	xpfe/appshell/src/nsXULWindow.cpp:1008
14 	xul.dll 	nsWebShellWindow::OnStateChange 	xpfe/appshell/src/nsWebShellWindow.cpp:563
15 	xul.dll 	nsDocLoader::DoFireOnStateChange 	uriloader/base/nsDocLoader.cpp:1305
16 	xul.dll 	nsDocLoader::doStopDocumentLoad 	uriloader/base/nsDocLoader.cpp:896
17 	xul.dll 	nsDocLoader::DocLoaderIsEmpty 	uriloader/base/nsDocLoader.cpp:775
18 	xul.dll 	nsDocLoader::OnStopRequest 	uriloader/base/nsDocLoader.cpp:659
19 	xul.dll 	nsLoadGroup::RemoveRequest 	netwerk/base/src/nsLoadGroup.cpp:697
20 	xul.dll 	nsDocument::DoUnblockOnload 	content/base/src/nsDocument.cpp:6970
21 	xul.dll 	nsUnblockOnloadEvent::Run 	content/base/src/nsDocument.cpp:6923
22 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:627
23 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:82
24 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/
25 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/
26 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:163
27 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:229
28 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:290
29 	xul.dll 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3823
30 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3890
31 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:4084

More reports at:*%29|+nsWindow%3A%3AProcessMessage%28unsigned+int%2C+unsigned+int%26%2C+long%26%2C+long*%29
It spiked also in 19.0a2 where it's #2 top crasher.

Here are the highest correlations in 19.0a2:
     61% (11/18) vs.   5% (50/984) {c0c9a2c7-2e5c-4447-bc53-97718bc91e1b} (Easy YouTube Video Downloader,
     39% (7/18) vs.   5% (48/984) (Ghostery,
     33% (6/18) vs.   4% (41/984)
     50% (9/18) vs.  23% (224/984) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus,
Keywords: topcrash
Version: 20 Branch → 19 Branch
Found in crash comments:

'There is a new HTML attribute that every time I use it FF will go down... <body onresize="">'

Jim - can you help investigate given that comment and the impacted add-ons?
Assignee: nobody → jmathies
Sort of a grab bag bug for any crash that happens when we deliver an event that flies off into dead memory.
Attached patch patch (obsolete) — Splinter Review
Jim, were you intending to ask for review on your patch?
Yeah, sorry, I pushed this to try and forgot about it. Will push again and hopefully remember to revisit once it completes.
Attachment #686756 - Attachment is obsolete: true
Comment on attachment 690834 [details] [diff] [review]
[landed] reorder WindowProcInternal v.2

This does some cleanup and moves the kungFuDeathGrip addref above a couple calls we make on targetWindow. I'm not expecting this to fix everything that shows up with this signature, but it's a start.
Attachment #690834 - Flags: review?(roc)
This might make a good tracking bug.
Whiteboard: [startupcrash] → [startupcrash][leave-open]
It has spiked across all channels since December 13.
(In reply to Scoobidiver from comment #11)
> It has spiked across all channels since December 13.*%29

I don't see this in crash. Care to elaborate scoobie? Also note lots of different crashes can end up under this top frame.
Odd, we have code specifically designed to keep the widget alive during show -

This was added in bug 492123, which was trying to fix this.
Depends on: 492123
Attachment #690834 - Attachment description: patch v.2 → [landed] reorder WindowProcInternal v.2
If things get torn down after UpdateWindow is called it's a bit more tricky, but lets assume for now it happens before the call and add paranoia checks prior to making it.
Attachment #692611 - Flags: review?(netzen)
Attachment #692611 - Flags: review?(netzen) → review+
I see no crashes with that signature in the Nightly build from the 18th as of now, so I think we should get this uplifted to 19.

jimm, can you request approval for that?
(In reply to Robert Kaiser ( from comment #19)
> I see no crashes with that signature in the Nightly build from the 18th as
> of now
Just to balance. There's only one crash in 20.0a1/20121218, bp-63c5ec57-3a7e-4fd2-89d2-2db312121219, while there were 27 in 20.0a1/20121217.

> so I think we should get this uplifted to 19.
(In reply to Scoobidiver from comment #20)
> Just to balance. There's only one crash in 20.0a1/20121218,
> bp-63c5ec57-3a7e-4fd2-89d2-2db312121219, while there were 27 in
> 20.0a1/20121217.

Ah, I was only looking for the @0x0 signature, and this is the other one with a non-null first frame.
Comment on attachment 692611 [details] [diff] [review]
protect UpdateWindow call in Show v.1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): unknown
User impact if declined: crashiness
Testing completed (on m-c, etc.): m-c (see comments)
Risk to taking this patch (and alternatives if risky): little to none
String or UUID changes made by this patch: none
Attachment #692611 - Flags: approval-mozilla-aurora?
As this bug is tracked, I am closing it. I filed bug 823160 for remaining crashes.
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [startupcrash][leave-open] → [startupcrash]
Target Milestone: --- → mozilla20
Attachment #692611 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Blocks: 823160
You need to log in before you can comment on or make changes to this bug.