User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100318 Minefield/3.7a4pre Firefox/3.6 Build Identifier: 20100318070109 Crash report: http://crash-stats.mozilla.com/report/index/a3e1f1c1-6bad-4121-8296-c801e2100318 Reproducible: Sometimes Steps to Reproduce: 1. Exit FF 2. 3. Actual Results: FF crashes. Expected Results: Exit FF without a crash Happens fairly often.

Seems to be caused by an houly. Went back to the nightly build and all is well. Build ID: 20100318040011

Confirming, setting to new. Will have to test more with a nightly since hourly's have on symbols. using hourly build with cset: http://hg.mozilla.org/mozilla-central/rev/a352d0413476 However, the crash could still be before that changeset.

Appears (so far) to only happen when I exit FF with a sidebar open. I'll wait for the nightly tomorrow.

Maybe caused by https://bugzilla.mozilla.org/show_bug.cgi?id=474060 - Patch has been backed out - will see later, or tomorrow if the crash persists

I just made a new build with the patch backed out and it didn't help. It seems to be related to how many tabs/windows are opened during a session.

Crash report from current nightly: http://crash-stats.mozilla.com/report/index/161b605a-32af-4d6f-aef9-8b8652100319 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100319 Minefield/3.7a4pre - Build ID: 20100319040017

The crashing cset is: http://hg.mozilla.org/mozilla-central/rev/002eb2e28e57 https://bugzilla.mozilla.org/show_bug.cgi?id=545228 https://bugzilla.mozilla.org/show_bug.cgi?id=552934 https://bugzilla.mozilla.org/show_bug.cgi?id=536081 Does not crash immediately if closed on open right away. Seems you have to have the browser open 15-20mins for the crash-on-close to occur. I let the nightly, build before this one, run over-night and closed this morning, no crash. Loading up and running the cset above after 20 mins crashed on close. Will run for another 20 mins with today's nightly, and hopefully will able to add a crash-report.

Today's nightly build, crash-report after closing browser after 20 mins: http://crash-stats.mozilla.com/report/pending/512cb745-17b7-40cd-9bff-b62d12100319 Appears to be same stack as comment 6 Win7 x64 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100319 Minefield/3.7a4pre Firefox/3.6 ID:20100319040017

Signature mozilla::widget::WindowHook::Lookup(unsigned int) UUID 512cb745-17b7-40cd-9bff-b62d12100319 Time 2010-03-19 05:50:50.357144 Uptime 1206 Last Crash 3282 seconds before submission Product Firefox Version 3.7a4pre Build ID 20100319040017 Branch 1.9.3 OS Windows NT OS Version 6.1.7600 CPU x86 CPU Info AuthenticAMD family 16 model 2 stepping 3 Crash Reason EXCEPTION_ACCESS_VIOLATION Crash Address 0xb8 User Comments crash on close Processor Notes Related Bugs OPE Bug 530962 NEW Taskbar tab preview crashes [@ mozilla::widget::WindowHook::Lookup(unsigned int)] in Firefox 3.6 Crashing Thread Frame Module Signature [Expand] Source 0 xul.dll mozilla::widget::WindowHook::Lookup widget/src/windows/WindowHook.cpp:99 1 xul.dll mozilla::widget::WindowHook::RemoveMonitor widget/src/windows/WindowHook.cpp:85 2 xul.dll mozilla::widget::TaskbarPreview::DetachFromNSWindow widget/src/windows/TaskbarPreview.cpp:239 3 xul.dll mozilla::widget::TaskbarPreview::~TaskbarPreview widget/src/windows/TaskbarPreview.cpp:117 4 xul.dll mozilla::widget::TaskbarTabPreview::~TaskbarTabPreview widget/src/windows/TaskbarTabPreview.cpp:74 5 xul.dll mozilla::widget::TaskbarTabPreview::`scalar deleting destructor' 6 xul.dll mozilla::widget::TaskbarTabPreview::Release widget/src/windows/TaskbarTabPreview.cpp:53 7 xul.dll DoDeferredRelease<nsISupports*> js/src/xpconnect/src/xpcjsruntime.cpp:489 8 xul.dll XPCJSRuntime::GCCallback js/src/xpconnect/src/xpcjsruntime.cpp:760 9 xul.dll DOMGCCallback dom/base/nsJSEnvironment.cpp:3732 10 mozjs.dll js_GC js/src/jsgc.cpp:3383 11 mozjs.dll JS_GC js/src/jsapi.cpp:2288 12 xul.dll xul.dll@0x97bd9b 13 xul.dll ScopedXPCOMStartup::~ScopedXPCOMStartup toolkit/xre/nsAppRunner.cpp:1051 14 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3593 15 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:120 16 firefox.exe __tmainCRTStartup obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591 17 kernel32.dll kernel32.dll@0x13676 18 ntdll.dll ntdll.dll@0x39d71 19 ntdll.dll ntdll.dll@0x39d44

I've been getting crashes on exit as well. http://crash-stats.mozilla.com/report/index/bp-e3b635c9-3849-4e37-9a85-d29c62100319 Oddly, it's only when I use StrataBuddy's "Restart" option. It doesn't require waiting 20 minutes for it to happen. Closing Firefox through the X button in the titlebar didn't crash me. (I did just restart Firefox, though. I'll wait the 20 minutes or so and try it again.)

Reported crashes: http://fwd4.me/IKo

Why did you re-add 'regression-window wanted' ? I'm pretty sure I found the regressing set of patches, unless you don't concur or have evidence that its not the causal cset.

took it out. I trust your sleuthing.

Looks like we've gone from leaking the world to deleting things too early.

Looks to me like we should be deleting the preview before the window. I'll have a patch for this tonight we can test.

sounds great

The reason I haven't duped the bug is because the regressing patch landed after that bug was filed, so there is more than one issue at work here.

i suspect the problem is that before we were not deleting anything, thus the leak on shutdown. Now that we correctly break cycles objects are collected, it is then possible something that goes away is not correctly null checked in the backend.

I'm going to throw this to the wind as it might be related. I've noticed jerky scrolling at various times on different sites. I can correct this by bringing up the W7 taskbar and hover over the FF icon until the preview window appears. Scrolling then is fine for page I was on. This seems to have started with the leak cleanup.

who guarantees that mWnd is still a valid window handle in the destructor? looks like just a cached value http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/TaskbarPreview.cpp#116

what about if (::isWindow(mWnd)) DetachFromNSWindow(PR_TRUE);

(In reply to comment #20) > who guarantees that mWnd is still a valid window handle in the destructor? > looks like just a cached value > http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/TaskbarPreview.cpp#116 There should be a WM_DESTROY hook for the nsWindow so we get notified when it disappears. That is probably not firing correctly (see bug 530962 comment 1). (In reply to comment #21) > what about > > if (::isWindow(mWnd)) > DetachFromNSWindow(PR_TRUE); It's entirely possible that that check could succeed because some other process (including our own) has made a new window that has the same handle (USER handles like HWNDs are not as well behaved as HANDLEs).