It's a low volume crash but started spiking on startup in 20.0a1/20121120. The regression range for the spike is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4fddb9923ef0&tochange=bc69705c162d 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 Reason EXCEPTION_ACCESS_VIOLATION_EXEC 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/message_loop.cc:208 25 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:182 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: https://crash-stats.mozilla.com/report/list?signature=nsWindow%3A%3AProcessMessage%28unsigned+int%2C+unsigned+int%26%2C+long%26%2C+long*%29 https://crash-stats.mozilla.com/report/list?signature=%400x0+|+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, https://addons.mozilla.org/addon/10137) 39% (7/18) vs. 5% (48/984) firefox@ghostery.com (Ghostery, https://addons.mozilla.org/addon/9609) 33% (6/18) vs. 4% (41/984) wrc@avast.com 50% (9/18) vs. 23% (224/984) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)

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?

Sort of a grab bag bug for any crash that happens when we deliver an event that flies off into dead memory.

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.

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.

This might make a good tracking bug.

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. https://crash-stats.mozilla.com/report/list?signature=nsWindow%3A%3AProcessMessage%28unsigned+int%2C+unsigned+int%26%2C+long%26%2C+long*%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.

(In reply to Jim Mathies [:jimm] from comment #12) > (In reply to Scoobidiver from comment #11) > > It has spiked across all channels since December 13. > Care to elaborate scoobie? Go to Graph tab: https://crash-stats.mozilla.com/report/list?version=Firefox:19.0a2&signature=%400x0+|+nsWindow%3A%3AProcessMessage%28unsigned+int%2C+unsigned+int%26%2C+long%26%2C+long*%29 https://crash-stats.mozilla.com/report/list?version=Firefox:20.0a1&signature=%400x0+|+nsWindow%3A%3AProcessMessage%28unsigned+int%2C+unsigned+int%26%2C+long%26%2C+long*%29

Odd, we have code specifically designed to keep the widget alive during show - http://hg.mozilla.org/mozilla-central/annotate/b11065872128/xpfe/appshell/src/nsXULWindow.cpp#l808 This was added in bug 492123, which was trying to fix this.

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.

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 (:kairo@mozilla.com) 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. Agreed.

(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

As this bug is tracked, I am closing it. I filed bug 823160 for remaining crashes.

The crashes for the last 4 weeks are: Firefox 19 beta - 72 crashes Firefox 20.0a2 - 1 crash Firefox 21.0a1 - 2 crashes https://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&reason_type=contains&range_value=4&range_unit=weeks&hang_type=any&process_type=any&signature=nsWindow%3A%3AProcessMessage%28unsigned%20int%2C%20unsigned%20int%26%2C%20long%26%2C%20long%2A%29 https://crash-stats.mozilla.com/report/list?signature=%400x0+|+nsWindow%3A%3AProcessMessage%28unsigned+int%2C+unsigned+int%26%2C+long%26%2C+long*%29 Marking this bug as verified considering that the remaining crashes are tracked in bug 823160.