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::Disable widget/src/windows/TaskbarPreview.cpp:237 3 xul.dll mozilla::widget::TaskbarTabPreview::Disable widget/src/windows/TaskbarTabPreview.cpp:254 4 xul.dll mozilla::widget::TaskbarPreview::SetVisible widget/src/windows/TaskbarPreview.cpp:163 5 xul.dll mozilla::widget::TaskbarTabPreview::SetVisible widget/src/windows/TaskbarTabPreview.h:61 6 xul.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102 7 xul.dll XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:2728 8 xul.dll XPC_WN_GetterSetter js/src/xpconnect/src/xpcwrappednativejsops.cpp:1806 9 mozjs.dll js_Invoke js/src/jsinterp.cpp:1364 10 mozjs.dll js_InternalInvoke js/src/jsinterp.cpp:1429 11 mozjs.dll js_SetPropertyHelper js/src/jsobj.cpp:5475 12 mozjs.dll js_Interpret js/src/jsops.cpp:1872 13 mozjs.dll js_Invoke js/src/jsinterp.cpp:1372 14 mozjs.dll js_InternalInvoke js/src/jsinterp.cpp:1429 15 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:4957 16 xul.dll nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:2161 17 xul.dll nsJSEventListener::HandleEvent dom/src/events/nsJSEventListener.cpp:228 18 xul.dll nsEventListenerManager::HandleEventSubType content/events/src/nsEventListenerManager.cpp:1082 19 xul.dll nsEventListenerManager::HandleEvent content/events/src/nsEventListenerManager.cpp:1198 20 xul.dll nsEventTargetChainItem::HandleEvent content/events/src/nsEventDispatcher.cpp:201 21 xul.dll nsEventTargetChainItem::HandleEventTargetChain content/events/src/nsEventDispatcher.cpp:326

Are you sure this still crashes? I can't find any crashes on crash-stats. Until we're sure of how frequently this happens, I will have to say this doesn't block.

(In reply to comment #1) > Are you sure this still crashes? I can't find any crashes on crash-stats. > > Until we're sure of how frequently this happens, I will have to say this > doesn't block. http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.7a4pre&platform=windows&query_search=signature&query_type=exact&query=mozilla%3A%3Awidget%3A%3AWindowHook%3A%3ALookup%28unsigned%20int%29&date=&range_value=1&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=mozilla%3A%3Awidget%3A%3AWindowHook%3A%3ALookup%28unsigned%20int%29 Looks like a bit less than 10/day.

I hit this today on shutdown: http://crash-stats.mozilla.com/report/index/bp-fb265a31-2f8e-4784-8378-79b182100421

I would really like to see a VMWare recording of this crash or some STR. If I had to guess what the state of the TaskbarTabPreview was, mWnd is non-NULL but nsWindow::GetNSWindowPtr is null which is a very odd state to be in.

I was getting this crash a couple of times, while minimizing a testcase for bug 584251. I got it while closing Minefield.

we had an older bug with the same signature (bug 530962), but this sounds like a recent volume regression on trunk. Around #11 or #12 topcrash on firefox 4.0b4 and b5, whereas the ranking on 3.6.9 is round #29. Could be the same crash in both releases and a way to calibrate the two, but we should also check for any code that might have changed that might have made this worse or created different bugs. we are running at about 1000 crashes per day across all releases and not the 10 per day mentioned in comment 2. Steady growth since June, but also some sharp spikes around July 20th date crash_count 20100601 147 20100602 123 20100603 105 20100604 110 20100605 106 20100701 216 20100702 207 20100703 224 20100704 214 20100705 243 20100718 314 20100719 355 20100720 504 20100721 2027 20100722 1526 20100723 688 20100724 934 20100725 912 20100801 879 20100802 897 20100803 858 20100804 845 20100805 900 20100901 1052 20100902 1091 20100903 971 20100904 938 20100905 1011

looks like that spike from July 21 is 3.6.7 volume but in pct. terms the trunk was also high there. checking --- mozilla::widget::WindowHook::Lookup.unsigned.int. 20100721-crashdata.csv found in: 3.6.7 3.6.6 4.0b1 3.6.3 4.0b2pre 3.6b5 3.6 3.6b2 3.6.2 4.0b3pre 3.7a2 3.6b4 3.6b3 3.6.8pre release total-crashes mozilla::widget::WindowHook::Lookup.unsigned.int. crashes pct. all 931161 2027 0.00217685 3.6.7 670536 1757 0.00262029 3.6.6 127716 143 0.00111967 4.0b1 20229 74 0.00365811 3.6.3 16172 26 0.00160772 4.0b2pre1471 11 0.00747791 also, any more thoughts on the connection to bug 584251 as suggested in comment 5?

in a sample of 100 crashes from yesterday looking at the top 6 frames of the stack it looks like there are 6 different stacks but might be variations of remove monitor and add monitor WindowHook::Lookup RemoveMonitor TaskbarPreview::DetachFromNSWindow http://crash-stats.mozilla.com/report/index/2bd64c8d-58c6-47ca-8273-e59712100912 and WindowHook::Lookup LookupOrCreate(unsigned int) WindowHook::AddMonitor http://crash-stats.mozilla.com/report/index/2eb892bf-ddcb-4c4b-b6c6-1f90f2100912

I'd like it renew my request from comment 3. It seems like this is a race condition that I am very unreliably able to hit on my own machine. If someone can catch this under VMWare R&R, I can (help) debug this remotely. This was invaluable towards solving a similar crash earlier this year in a matter of an hour vs the hours I spent staring at the source.

One of the comments in the breakpad reports mentioned the MaxTo program, which makes Firefox crash reproducible with this stacktrace on shutdown. I filed bug 596222 for it. Other instances when people are crashing with this stacktrace, that I've noticed. - Directly on startup. - While a (flash) plugin seems to be chewing up all cpu, causing Firefox to hang. Then the user tries to close Firefox.

When this crash occurs, during shutting down firefox process, window is destroyed at first, then, TaskbarWindowPreview is detroyed (depeded on GC). So TaskbarWindowPreview uses invalid hook object. So I think that all hooks may have to watch WM_DESTORY. As long as I check crash reporter' log, this crash still occurs on 4.0b7pre http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0b7pre&query_search=signature&query_type=startswith&query=mozilla%3A%3Awidget%3A%3AWindowHook%3A%3ALookup&date=10%2F04%2F2010%2023%3A39%3A16&range_value=1&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=mozilla%3A%3Awidget%3A%3AWindowHook%3A%3ALookup%28unsigned%20int%29

(In reply to comment #12) > When this crash occurs, during shutting down firefox process, window is > destroyed at first, then, TaskbarWindowPreview is detroyed (depeded on GC). So > TaskbarWindowPreview uses invalid hook object. So I think that all hooks may > have to watch WM_DESTORY. Does this mean that you can reliably reproduce the crash? (I cannot). I'm curious how we're destroying the nsWindow because I'm pretty sure I verified 6+ months ago that all destruction paths did proper cleanup/notification.

(In reply to comment #13) > Does this mean that you can reliably reproduce the crash? (I cannot). I'm > curious how we're destroying the nsWindow because I'm pretty sure I verified 6+ > months ago that all destruction paths did proper cleanup/notification. I cannot reproduce this, but I think that crash reason is clear if you analyze stack and imagine situation why crashing. mozilla::widget::WindowHook is already destroyed when crash occurs. It mean this of WindowHook is NULL. This bug depends on GC timing. (when TaskbarTabPreview is destroyed by GC.) And root cause is that TaskbarPreview doesn't know whether WindowHook is alive.

GC bugs usually are concetrated on winXP or across OSes. Its strange that this one might be exclusively win7 os breakdown for crashes on 2010 10 20 1064 Windows NT 6.1. mozilla::widget::WindowHook::Lookup(unsigned int) 1061 0.99718 Windows NT6.1.7600 1 0.00093985 Windows NT6.1.7601 Service Pack 2, v.172 1 0.00093985 Windows NT6.1.7601 Service Pack 1, v.153 1 0.00093985 Windows NT6.1.7100 looking at possible test urls there are these indicate possible private browsing and downloading activity going on. they might help to tickle GC 61 about:blank 51 \N 12 about:privatebrowsing 9 http://get.adobe.com/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&a=McAfee_Security_Scan_Plus&os=Wind ows%207&browser=Firefox&type=xpi 7 http://get.adobe.com/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&d=McAfee_Security_Scan_Plus&os=Wind ows%207&browser=Firefox&type=xpi 3 http://ff.conduit-download.com/27/243/ct2438727/downloads/firefox/releases/2.7.1.3/10-06-30-00.13.44.677/zynga.xpi 2 http://get2.adobe.com/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&a=McAfee_Security_Scan_Plus&os=Win dows%207&browser=Firefox&type=xpi 2 http://get.adobe.com/reader/download/?installer=Reader_9.4_English_for_Windows&a=McAfee_Security_Scan_Plus&a=ARH&a=Air_Installer&os=Win dows%207&browser=Firefox&type=xpi 2 http://get.adobe.com/fr/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&d=McAfee_Security_Scan_Plus&os=W indows%207&browser=Firefox&type=xpi 2 http://get.adobe.com/es/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&a=McAfee_Security_Scan_Plus&os=W indows%207&browser=Firefox&type=xpi 2 http://get.adobe.com/de/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&a=McAfee_Security_Scan_Plus&os=W indows%207&browser=Firefox&type=xpi some facebook activity 8 http://www.facebook.com/#!/ 6 http://www.google.de/ 6 http://www.facebook.com/?ref=home 6 http://www.facebook.com/ 2 http://apps.facebook.com/frontierville/?crt&aff=bookmarks&src=bookmark&newUser&sendkey&ref=bookmarks 2 http://apps.facebook.com/cartown/?ref=bookmarks&count=0 justin tv and google talk gaget wyciwyg cache 1 wyciwyg://68/http://www.justin.tv/family_guy_5ucks_b4lls 1 wyciwyg://3/http://talkgadget.google.com/talkgadget/notifierclient?client=sm&prop=Orkut&nav=true&fid=gtn-roster-iframe-id&ts=0&debug=un defined&os=Win32&stime=1287597752609&fb=false&re=false&no=undefined&hc=undefined&ref=undefined&xpc=%7B%22cn%22%3A%22idku 1 wyciwyg://3/http://ru.justin.tv/radiotrance_189 1 wyciwyg://15/http://sn140w.snt140.mail.live.com/mail/InboxLight.aspx?n=444610932 and some session restore/(re-)startup 5 jar:file:///C:/Program%20Files/Mozilla%20Firefox%204.0%20Beta%205/omni.jar!/chrome/browser/content/browser/aboutSessionRestore.xhtml 5 http://www.yahoo.com/ 5 http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official 4 http://www.google.com/ig?refresh=1 3 http://www.orkut.com/Logout?msg=0&hl=pt-BR 3 http://www.mozilla.com/en-US/firefox/3.6.11/whatsnew/ 3 http://www.google.com/ig 3 http://www.facebook.com/home.php?#!/ 3 http://de.start3.mozilla.com/firefox?client=firefox-a&rls=org.mozilla:de:official 2 https://suomi.sampopankki.fi/link/FuncStat?opendocument&FuncStat=eSecureKeyFIInit 2 https://mail.google.com/mail/?shva=1#inbox 2 http://www.yandex.ru/ 2 http://www.google.de/firefox?client=firefox-a&rls=org.mozilla:de:official 10 http://en-us.start3.mozilla.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official

also a bunch of viewing of pages on addons.mozilla.org and possible download and installation of addons going on. some kind of downloading (maybe while in private browsing) while viewing videos or playing games on facebook to generally keep the browser busy, then shut down? https://bugzilla.mozilla.org/show_bug.cgi?id=584251#c7 has Martiin's test case where he was testing that other bug and stubbled on to this signature. The key there was also getting the browser at high levels of activity then trying to shut down.

(In reply to comment #14) > (In reply to comment #13) > > > Does this mean that you can reliably reproduce the crash? (I cannot). I'm > > curious how we're destroying the nsWindow because I'm pretty sure I verified 6+ > > months ago that all destruction paths did proper cleanup/notification. > > I cannot reproduce this, but I think that crash reason is clear if you analyze > stack and imagine situation why crashing. > mozilla::widget::WindowHook is already destroyed when crash occurs. It mean > this of WindowHook is NULL. > > This bug depends on GC timing. (when TaskbarTabPreview is destroyed by GC.) And > root cause is that TaskbarPreview doesn't know whether WindowHook is alive. It should though because each TaskbarPreview listens for WM_DESTROY and explicitly marks that the window is gone by setting mWnd to NULL. My guess is that we're not getting these sometimes. I've attached a possible fix which makes sure that we dispatch those in the case where our toplevel window is for some reason subclassed and dropping WM_DESTROY messages. I don't understand the teardown code very well so I am asking Jim to review this to see if that sounds plausible.

I don't understand why we think this will address the problem. Do we really think sub classes that filter the destroy message are this common?

(In reply to comment #18) > I don't understand why we think this will address the problem. Do we really > think sub classes that filter the destroy message are this common? I'm out of other ideas (please feel free to suggest issues) so I am resorting to trying to prove that all code paths are safe. Unless someone catches this under VMWare Record & Reply or comes up with reliable steps to reproduce, I don't think this will get fixed.

Comment on attachment 485157 [details] [diff] [review] Ensure we dispatch WM_DESTROY if we're subclassed Unless this drops the occurrences to zero, lets keep this open. I can find some time to play with this in a recording session.

Let's keep this open until the crash stats show it's fixed.

http://crash-stats.mozilla.com/report/list?product=Firefox&branch=2.0&platform=windows&query_search=signature&query_type=exact&query=mozilla%3A%3Awidget%3A%3AWindowHook%3A%3ALookup%28unsigned%20int%29&date=11%2F29%2F2010%2011%3A58%3A26&range_value=4&range_unit=weeks&hang_type=crash&process_type=browser&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=mozilla%3A%3Awidget%3A%3AWindowHook%3A%3ALookup%28unsigned%20int%29 (the occurrences of this crash on Windows in the last 4 weeks, on mozilla-central Windows builds, including betas) suggests that it's not fixed (see the "Table" tab for table-by-build). Is Rob Arnold still the right owner for this bug?

I tihnk so.

here is an update on volume across releases. lets recheck these numbers after beta8 checking --- mozilla::widget::WindowHook::Lookup.unsigned.int. 20101213-crashdata.csv found in: 3.6.13 4.0b7 3.6.12 3.6.3 3.6 3.6.8 4.0b6 3.6.2 3.6.10 3.6b5 3.6b4 4.0b8pre 4.0b4 3.6b2 4.0b1 3.6b3 3.6.9 3.6.7 3.6.6 4.0b5 4.0b3 release total-crashes mozilla::widget::WindowHook::Lookup.unsigned.int. crashes pct. all 338233 1124 0.00332315 3.6.13 164371 367 0.00223275 4.0b7 42486 282 0.00663748 3.6.12 46897 175 0.00373158 3.6.3 7848 146 0.0186035 3.6 5247 63 0.0120069 3.6.8 7317 21 0.00287003 4.0b6 2848 13 0.00456461 3.6.2 1507 16 0.0106171 3.6.10 7657 12 0.00156719 3.6b5 632 6 0.00949367 3.6b4 425 5 0.0117647 4.0b8pre5689 4 0.000703111 4.0b4 880 4 0.00454545 3.6b2 339 3 0.00884956 4.0b1 814 2 0.002457

rank is #33 on 3.6.13 v. #14 on 4.0b7

This is definitely not fixed. Mounir, do you have Windows? Without a testcase, or steps to reproduce, we might need to null-check our way to victory. Some of the stacks are unusual: https://crash-stats.mozilla.com/report/index/b52046cd-8863-4409-b420-ddd122110131 https://crash-stats.mozilla.com/report/index/c513b766-15f6-4130-ba70-c2d9b2110201 Here we're actually crashing on creating the preview, because we get a null hook. I wonder if we could possible be getting an mWnd that has *already* had WM_DESTROY called on it? Maybe we should try checking in CreateTaskbarTabPreview whether the nsWindow for the toplevelHWND can be found, and refuse to create the preview if not. That's wallpaper-ish but it's safe and will either make these crashes go away or narrow down the problem.

(In reply to comment #27) > This is definitely not fixed. > > Mounir, do you have Windows? Unfortunately, I don't. But I'm planning to install a VM on my desktop so I will have a look at that bug at this moment if it's not fixed in the mean time.

Worth a shot. Many of the comments suggest plugin interactions (flash games, divx), so something might be generating messages at unexpected times. There are also some startup crashes, which are even weirder. I thought bug 608589 might be related to this but it's been marked as fixed for 4b10 and this crash didn't disappear

I don't think we should wait for rob's review here. Just land it!

Landed http://hg.mozilla.org/mozilla-central/rev/019e47cc11e2 I'll keep the r? if rob wants to take a look

Comment on attachment 509572 [details] [diff] [review] Check for nsWindow existence before creating the preview I'm pretty sure this will cause UI bustage in the error case since other parts of the frontend code assume a 1:1 correspondence of tabs and previews. I also don't think this code had proper review for the browser/ part so it should not have landed.

OK, we can back it out. However, I think that some kind of UI bustage is preferable to crashing.

At least I think we should leave it in for a few days to a) see if it fixed the crashes and b) see if anyone notices UI bustage that could be related to this.

I still see this crash signature in builds from 4 Feb on...

I'm renominating this bug as a hardblocker because we should remember to backout the latest test patch before the final version, it was uneffective, plus comment 32.

OK. Felipe, can you back this out?

I can

Backed out at http://hg.mozilla.org/mozilla-central/rev/d05be9356e44

Felipe, did you meant to change this bug from hardblocker to softblocker?

Yeah, it was a softblocker before, we just marked hardblocker to remember to back out the last fix attempt

** PRODUCT DRIVERS PLEASE NOTE ** This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons: - it was marked as a soft blocking issue without a requirement for beta coverage

https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Awidget%3A%3AWindowHook%3A%3ALookup%28unsigned%20int%29 says this signature happens across the board - what's the status of this? I guess the "3.6" can be removed from the summary?

This crash still appears on recent. Looks like a Windows 7 specific issue. On 9.0b3 there are 150 crashes total so far. On 8.0 we had over 3000 in the past 4 weeks.

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #11) > - Directly on startup. Should startup crashes be considered in a different bug? I have a user who, after updating to version 10, is now crashing on startup. Reinstall doesn't help. Safe mode starts, but the safe mode window is empty. His crashes are bp-3c619a32-20f5-41fe-98fb-520482120213 bp-0e9ce577-2657-49a8-ab06-568d22120213 other users startup crashes: bp-bc5c9b4e-e1a2-4805-9728-b35ee2120120 bp-6b2c1bb6-271f-4331-9aca-32f252120207 bp-57c8034e-146d-42bc-a6b0-964312120205 bp-23f158d0-2158-4b13-95f4-a77de2120212

here is what we had seen starting safemode (In reply to Wayne Mery (:wsmwk) from comment #45) > Should startup crashes be considered in a different bug? > > I have a user who, after updating to version 10, is now crashing on startup. > Reinstall doesn't help. Safe mode starts, but the safe mode window is empty. > His crashes are > bp-3c619a32-20f5-41fe-98fb-520482120213 > bp-0e9ce577-2657-49a8-ab06-568d22120213 after rebooting his win7 system, firefox now starts

Confirm for Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121010030605 Crash: https://crash-stats.mozilla.com/report/index/bp-6bb5f3f1-49fe-457e-81d8-cc8082121011

Not at all frequent, but it is still around in Fx39. From a sumo thread. bp-9a711c79-b774-414a-b14a-e5e5d2150723 Windows NT OS Version 6.1.7601 Service Pack 1 Firefox 39.0 Build ID 20150630154324 > User Comments I was shutting down my PC and clicked on Firefox menu (3 bars), to the right at the top of the screen, so that I may properly close down Firefox. When the Firefox menu opened I clicked on the 'close' button and then up popped the Mozilla Crash Reporter. As I had closed everything down I would not have known that Firefox has crashed except for this Crash Reporting making itself available, did i I had closed all pages and had nothing open, no applications, no tab. Nothing was open. I will ask the user for more information, or ask the person to post here if it helps at all. The user has remarked along the lines that Firefox is now used regularly but has not crashed often.

Based on Socorro reports from last 28 days, this crash is encounter frequently. We shouldn't close this issue until there are no more crashes.

This is still occurring in the wild on release branches (including beta). However, no reports against dev branches.

Crash volume for signature 'mozilla::widget::WindowHook::Lookup': - nightly (version 51): 12 crashes from 2016-08-01. - aurora (version 50): 39 crashes from 2016-08-01. - beta (version 49): 244 crashes from 2016-08-02. - release (version 48): 475 crashes from 2016-07-25. - esr (version 45): 583 crashes from 2016-05-02. Crash volume on the last weeks (Week N is from 08-22 to 08-28): W. N-1 W. N-2 W. N-3 - nightly 3 3 3 - aurora 14 16 3 - beta 89 84 26 - release 145 132 82 - esr 71 55 57 Affected platform: Windows Crash rank on the last 7 days: Browser Content Plugin - nightly #187 - aurora #95 - beta #188 - release #125 - esr #114