492123 - Crash [@ _purecall | nsWindow::Show(int)] with onblur alert and doing print preview

Status: RESOLVED FIXED

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

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, to reproduce the bug, open the testcase, then do print preview.
After clicking away the 'alert' alert, you get a crash in current trunk build.

http://crash-stats.mozilla.com/report/index/89541506-f1c3-4842-b9b3-d9d5a2090508?p=1
0  	ntdll.dll  	ntdll.dll@0xe514  	
1 	kernel32.dll 	kernel32.dll@0x2541 	
2 	xul.dll 	google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread 	toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:562
3 	xul.dll 	google_breakpad::ExceptionHandler::HandlePureVirtualCall 	toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:506
4 	mozcrt19.dll 	_purecall 	obj-firefox/memory/jemalloc/crtsrc/purevirt.c:47
5 	xul.dll 	nsWindow::Show 	widget/src/windows/nsWindow.cpp:1717
6 	xul.dll 	nsXULWindow::SetVisibility 	xpfe/appshell/src/nsXULWindow.cpp:782
7 	xul.dll 	nsXULWindow::OnChromeLoaded 	xpfe/appshell/src/nsXULWindow.cpp:1005
8 	xul.dll 	nsWebShellWindow::OnStateChange 	xpfe/appshell/src/nsWebShellWindow.cpp:661
9 	xul.dll 	nsDocLoader::FireOnStateChange 	uriloader/base/nsDocLoader.cpp:1259
10 	xul.dll 	xul.dll@0x8d006f

Comment 1

[Martijn Wargers (dead)]

This regressed between 2008-07-17 and 2008-07-19:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-07-17+04%3A00%3A00&enddate=2008-07-19+06%3A00%3A00
I think a regression from bug 434089.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

> I think a regression from bug 434089

The patch in question
(http://hg.mozilla.org/mozilla-central/rev/b3770a76511b) is quite
small.  Could someone try reversing it by hand, and let us know if
this fixes the crash?

I'll try to get to this next week.  I can build on Windows ... but
only painfully.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

I just did a Windows build, based on current trunk code, with my patch for bug
434089 (http://hg.mozilla.org/mozilla-central/rev/b3770a76511b) backed out.

I still crash with it using this bug's testcase.  So I figure my patch has
nothing to do with the crash.

Comment 4

[Martijn Wargers (dead)]

Regression from bug 444013 then, somehow?

Comment 5

[Rob Arnold [:robarnold]]

(In reply to comment #4)
> Regression from bug 444013 then, somehow?
Seems unlikely since it didn't crash in the theme code (ours or Microsoft's). I don't have a debug build handy to try reversing or debugging, but from looking at mxr and the provided stack trace it seems like we're making a pure virtual call to Invalidate. Since nsWindow has an implementation of Invalidate, this suggests to me that 'this' is an invalid nsWindow...perhaps this is a use-after-free bug?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This stack is the #5 topcrash in 3.6b1.  Should that topcrash be tracked in this bug or a different one?

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

...that's 3.6b1 in testing before it shipped, I should say.

Comment 8

[Makoto Kato [:m_kato]]

confirm with latest m-c.

nsWindow is destroyed the following stack.

0:000> k 100
ChildEBP RetAddr
0014f358 6b897a60 xul!nsWindow::~nsWindow
0014f360 6b897b67 xul!nsWindow::`scalar deleting destructor'+0x8
0014f374 6b88fa02 xul!nsBaseWidget::Release+0x79
0014f380 6b9423e4 xul!nsWindow::Release+0xa
0014f38c 6b895ac1 xul!nsCOMPtr_base::~nsCOMPtr_base+0x1e
0014f3b8 76328817 xul!nsWindow::WindowProc+0xf6
0014f3e4 7632898e USER32!InternalCallWinProc+0x23
0014f45c 76329d14 USER32!UserCallWinProcCheckWow+0x109
0014f4b8 76329d85 USER32!DispatchClientMessage+0xe0
0014f4f4 7742e476 USER32!__fnDWORD+0x2b
0014f508 01591d50 ntdll!KiUserCallbackDispatcher+0x2e
0014f558 6b756ecb 0x1591d50
0014f578 6b75a4b8 xul!nsXULWindow::SetVisibility+0x56
0014f5ac 6b7545be xul!nsXULWindow::OnChromeLoaded+0x108
0014f5c0 6b71103a xul!nsWebShellWindow::OnStateChange+0x88
0014f65c 6b711732 xul!nsDocLoader::FireOnStateChange+0x13b
0014f6d4 6b711d62 xul!nsDocLoader::doStopDocumentLoad+0x8b
0014f708 6b7120b5 xul!nsDocLoader::DocLoaderIsEmpty+0x184
0014f798 6b1038b3 xul!nsDocLoader::OnStopRequest+0x248
0014f834 6b27fc45 xul!nsLoadGroup::RemoveRequest+0x1a2
0014f860 6b2851b6 xul!nsDocument::DoUnblockOnload+0x95
0014f864 6b46520b xul!nsDocument::UnblockOnload+0x6f
0014f878 6b462d6b xul!nsBindingManager::DoProcessAttachedQueue+0x7b
0014f87c 6b96e255 xul!nsRunnableMethod<nsBindingManager,void>::Run+0xe
0014f8a0 6b947a14 xul!nsThread::ProcessNextEvent+0x13e
0014f8b4 6b8a494f xul!NS_ProcessNextEvent_P+0x3d
0014f8cc 6b767f64 xul!nsBaseAppShell::Run+0x43
0014f8d8 6b061f48 xul!nsAppStartup::Run+0x47
0014fb60 00ba1941 xul!XRE_main+0x1afd
0014fba0 00ba1ad4 firefox!NS_internal_main+0x1e7
0014fbd4 00ba46d8 firefox!wmain+0xf3
0014fc24 00ba451f firefox!__tmainCRTStartup+0x1a8
0014fc2c 7646eccb firefox!wmainCRTStartup+0xf
0014fc38 7748d24d kernel32!BaseThreadInitThunk+0xe
0014fc78 7748d45f ntdll!__RtlUserThreadStart+0x23
0014fc90 00000000 ntdll!_RtlUserThreadStart+0x1b

Then, crash!

0:000> k
ChildEBP RetAddr
0014f558 6b756ecb xul!nsWindow::Show+0x120
0014f578 6b75a4b8 xul!nsXULWindow::SetVisibility+0x56
0014f5ac 6b7545be xul!nsXULWindow::OnChromeLoaded+0x108
0014f5c0 6b71103a xul!nsWebShellWindow::OnStateChange+0x88
0014f65c 6b711732 xul!nsDocLoader::FireOnStateChange+0x13b
0014f6d4 6b711d62 xul!nsDocLoader::doStopDocumentLoad+0x8b
0014f708 6b7120b5 xul!nsDocLoader::DocLoaderIsEmpty+0x184
0014f798 6b1038b3 xul!nsDocLoader::OnStopRequest+0x248
0014f834 6b27fc45 xul!nsLoadGroup::RemoveRequest+0x1a2
0014f860 6b2851b6 xul!nsDocument::DoUnblockOnload+0x95
0014f864 6b46520b xul!nsDocument::UnblockOnload+0x6f
0014f878 6b462d6b xul!nsBindingManager::DoProcessAttachedQueue+0x7b
0014f87c 6b96e255 xul!nsRunnableMethod<nsBindingManager,void>::Run+0xe
0014f8a0 6b947a14 xul!nsThread::ProcessNextEvent+0x13e
0014f8b4 6b8a494f xul!NS_ProcessNextEvent_P+0x3d
0014f8cc 6b767f64 xul!nsBaseAppShell::Run+0x43
0014f8d8 6b061f48 xul!nsAppStartup::Run+0x47
0014fb60 00ba1941 xul!XRE_main+0x1afd
0014fba0 00ba1ad4 firefox!NS_internal_main+0x1e7
0014fbd4 00ba46d8 firefox!wmain+0xf3

I will consider a fix (or backout bug 444013).

Comment 9

[Makoto Kato [:m_kato]]

depend on bug 434089, not bug 444013

Comment 10

[Joe Drew (not getting mail)]

This also crashes in 3.5.4, so it's not a regression, and therefore shouldn't block the release of 3.6.

Comment 11

[Martijn Wargers (dead)]

(In reply to comment #10)
> This also crashes in 3.5.4, so it's not a regression,

See comment 1 for the regression range.

Comment 12

[Joe Drew (not getting mail)]

Sure. I simply meant it's not a regression from 3.5 -> 3.6, and that matters when it comes to blocking.

Comment 13

[Martijn Wargers (dead)]

David Baron mentioned in comment 6 that this could be a topcrash, so I still think it should be considered blocking.

Comment 14

[Samuel Sidler (old account; do not CC)]

It's *not*, however, a topcrash for Firefox 3.5.4. It has 31 crashes in the last week, compared to 7209 for the current #1 crash. We should still fix it though... in the name of stability! :)

Comment 15

[Martijn Wargers (dead)]

I was not talking about Firefox3.5.4, I was talking about blocking1.9.2.

Comment 16

[Marcia Knous [:marcia]]

A relatively easy way to repro this crash is to install the Google Toolbar in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b1) Gecko/20091029 Firefox/3.6b1 GTB6, then click on the "add new button" in the toolbar. You will crash 100% of the time. My Win 7 machine in the lab can repro it easily.

Comment 17

[Makoto Kato [:m_kato]]

Attachment: patch

does anyone has or makes test xul/script for unit test?

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #12)
> Sure. I simply meant it's not a regression from 3.5 -> 3.6, and that matters
> when it comes to blocking.

So do we need a different bug for the fact that there are a lot more crashes with this signature in 3.6b1 than there were in 3.5.*?

Comment 19

[timeless]

Comment on attachment 410119 [details] [diff] [review]
patch 

this should be kungFuDeathGrip

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I would like to understand the bug better so we can put a useful comment in the patch.

It seems from the stack in comment #8 that calling Show() can send a Windows message that reenters nsWindow and somehow causes the window to be torn down? What Windows message is that, and how can it end up tearing down the window?

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Does anybody know if this represents the 3.6b1 topcrash or if I should file a separate bug?  (i.e, can anybody answer comment 6 or comment 18?)

Comment 22

[Marcia Knous [:marcia]]

If this helps, the crash report I get from Martijn's testcase is http://crash-stats.mozilla.com/report/index/bp-788b2166-695a-4182-8bbf-637fe2091106. The crash I get when I click the Add New Button widget with Google toolbar is http://crash-stats.mozilla.com/report/index/bp-1e904f8e-9ee2-4866-916e-9d52c2091106. I am using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b2pre) Gecko/20091106 Namoroka/3.6b2pre GTB6 (.NET CLR 3.5.30729) to reproduce.

Currently this stack is the #4 top crash for Firefox 3.6b1. Perhaps more crashes correlate to the popularity of the Google Toolbar?

Comment 23

[Makoto Kato [:m_kato]]

(In reply to comment #20)
> I would like to understand the bug better so we can put a useful comment in the
> patch.
> 
> It seems from the stack in comment #8 that calling Show() can send a Windows
> message that reenters nsWindow and somehow causes the window to be torn down?
> What Windows message is that, and how can it end up tearing down the window?

OK.  I am investigating this again.  Now I become clear the following...

It seems to depend on window message order for focus.  And Google Toolbar seems to call window.close() on focus event...  

When this problem occurs, the window message for focus is received into window proc of nsXULWindow::OnChromeLoaded().

002bb3a8 6791c407 xul!nsGlobalWindow::Close+0x3e5
002bb3b4 66a33058 xul!NS_InvokeByIndex_P+0x27
002bb798 66a46917 xul!XPCWrappedNative::CallMethod+0x1358
002bb864 6fe3c56d xul!XPC_WN_CallMethod+0x227
002bb93c 6fe4e3f6 mozjs!js_Invoke+0x8dd
002bbf78 6fe3c5b2 mozjs!js_Interpret+0xf986
002bc040 6fe2c097 mozjs!js_Invoke+0x922
002bc08c 6fe4e298 mozjs!js_fun_apply+0x2d7
002bc6c4 6fe3c5b2 mozjs!js_Interpret+0xf828
002bc78c 66aaeeb8 mozjs!js_Invoke+0x922
002bcb00 66ab3d61 xul!nsXPCWrappedJSClass::CallMethod+0x1058
002bcb20 6797b507 xul!nsXPCWrappedJS::CallMethod+0x41
002bcbf4 6797b1d6 xul!PrepareAndDispatch+0x317
002bcc10 66d4342f xul!SharedStub+0x16
002bcdc4 66d43899 xul!nsEventListenerManager::HandleEventSubType+0x2df
002bce34 66ed272d xul!nsEventListenerManager::HandleEvent+0x3c9
002bce6c 66ed28c9 xul!nsEventTargetChainItem::HandleEvent+0x11d
002bceac 66ed342d xul!nsEventTargetChainItem::HandleEventTargetChain+0xc9
002bcfd0 66e2942d xul!nsEventDispatcher::Dispatch+0x7cd
002bd048 66e28f01 xul!nsFocusManager::SendFocusOrBlurEvent+0x1fd
002bd0e4 66e2665a xul!nsFocusManager::Focus+0x2d1
002bd198 675a9810 xul!nsFocusManager::WindowRaised+0x49a
002bd254 677cc6ea xul!nsWebShellWindow::HandleEvent+0x430
002bd260 677cc7c2 xul!nsWindow::DispatchEvent+0x3a
002bd27c 677cd740 xul!nsWindow::DispatchWindowEvent+0x22
002bd2e0 677cd66e xul!nsWindow::DispatchFocus+0xc0
002bd2f8 677cf17f xul!nsWindow::DispatchFocusToTopLevelWindow+0x5e
002bd8cc 677cda42 xul!nsWindow::ProcessMessage+0x13cf
002bd920 75548817 xul!nsWindow::WindowProc+0x162
002bd94c 7554898e USER32!InternalCallWinProc+0x23
002bd9c4 75549d14 USER32!UserCallWinProcCheckWow+0x109
002bda20 75549d85 USER32!DispatchClientMessage+0xe0
002bda5c 772be476 USER32!__fnDWORD+0x2b
002bda70 014d1000 ntdll!KiUserCallbackDispatcher+0x2e
002bdb1c 75549dcc 0x14d1000
002bdb3c 75549e29 USER32!RealDefWindowProcW+0x4a
002bdb84 75548817 USER32!DefWindowProcW+0x6f
002bdbb0 7554898e USER32!InternalCallWinProc+0x23
002bdc28 7554c47c USER32!UserCallWinProcCheckWow+0x109
002bdc60 7554c4a2 USER32!CallWindowProcAorW+0xa9
002bdc80 677cda8c USER32!CallWindowProcW+0x1b
002bdcd8 75548817 xul!nsWindow::WindowProc+0x1ac
002bdd04 7554898e USER32!InternalCallWinProc+0x23
002bdd7c 75549d14 USER32!UserCallWinProcCheckWow+0x109
002bddd8 75549d85 USER32!DispatchClientMessage+0xe0
002bde14 772be476 USER32!__fnDWORD+0x2b
002bde28 014d1000 ntdll!KiUserCallbackDispatcher+0x2e
002bde80 675ae28a 0x14d1000
002bdec0 675a802a xul!nsXULWindow::SetVisibility+0x9a
002bded0 66e26443 xul!nsChromeTreeOwner::SetVisibility+0x4a
002bdf74 675a9810 xul!nsFocusManager::WindowRaised+0x283
002be030 677cc6ea xul!nsWebShellWindow::HandleEvent+0x430
002be03c 677cc7c2 xul!nsWindow::DispatchEvent+0x3a
002be058 677cd740 xul!nsWindow::DispatchWindowEvent+0x22
002be0bc 677cd66e xul!nsWindow::DispatchFocus+0xc0
002be0d4 677cf17f xul!nsWindow::DispatchFocusToTopLevelWindow+0x5e
002be6a8 677cda42 xul!nsWindow::ProcessMessage+0x13cf
002be6fc 75548817 xul!nsWindow::WindowProc+0x162
002be728 7554898e USER32!InternalCallWinProc+0x23
002be7a0 75549d14 USER32!UserCallWinProcCheckWow+0x109
002be7fc 75549d85 USER32!DispatchClientMessage+0xe0
002be838 772be476 USER32!__fnDWORD+0x2b
002be84c 014eef60 ntdll!KiUserCallbackDispatcher+0x2e
002be8f8 75549dcc 0x14eef60
002be918 75549e29 USER32!RealDefWindowProcW+0x4a
002be960 75548817 USER32!DefWindowProcW+0x6f
002be98c 7554898e USER32!InternalCallWinProc+0x23
002bea04 7554c47c USER32!UserCallWinProcCheckWow+0x109
002bea3c 7554c4a2 USER32!CallWindowProcAorW+0xa9
002bea5c 677cda8c USER32!CallWindowProcW+0x1b
002beab4 75548817 xul!nsWindow::WindowProc+0x1ac
002beae0 7554898e USER32!InternalCallWinProc+0x23
002beb58 75549d14 USER32!UserCallWinProcCheckWow+0x109
002bebb4 75549d85 USER32!DispatchClientMessage+0xe0
002bebf0 772be476 USER32!__fnDWORD+0x2b
002bec04 014eef60 ntdll!KiUserCallbackDispatcher+0x2e
002bec48 675ae28a 0x14eef60
002bec88 675aed6b xul!nsXULWindow::SetVisibility+0x9a
002beccc 675a9c0e xul!nsXULWindow::OnChromeLoaded+0x1ab
002becf4 67539875 xul!nsWebShellWindow::OnStateChange+0xfe
002beda0 67538abc xul!nsDocLoader::FireOnStateChange+0x1f5
002bee24 675386b2 xul!nsDocLoader::doStopDocumentLoad+0xbc
002bee6c 67538733 xul!nsDocLoader::DocLoaderIsEmpty+0x232
002bee7c 675386d1 xul!nsDocLoader::ChildDoneWithOnload+0x23
002beec0 67538380 xul!nsDocLoader::DocLoaderIsEmpty+0x251
002bef90 66af683f xul!nsDocLoader::OnStopRequest+0x3b0
002bf03c 66d8826d xul!nsLoadGroup::RemoveRequest+0x23f
002bf064 66d88027 xul!nsDocument::DoUnblockOnload+0xed
002bf074 66d7f42c xul!nsDocument::UnblockOnload+0xc7
002bf104 66d8cc24 xul!nsDocument::DispatchContentLoadedEvents+0x34c
002bf10c 67943dca xul!nsRunnableMethod<nsDocument,void>::Run+0x24
002bf148 678f61b3 xul!nsThread::ProcessNextEvent+0x1fa
002bf164 677c773a xul!NS_ProcessNextEvent_P+0x53
002bf178 675ca87a xul!nsBaseAppShell::Run+0x5a
002bf18c 669d7b5c xul!nsAppStartup::Run+0x6a
002bf7f8 01122572 xul!XRE_main+0x30dc
002bf85c 01121d2e firefox!NS_internal_main+0x2b2
002bf890 011276a8 firefox!wmain+0x11e
002bf8e0 011274ef firefox!__tmainCRTStartup+0x1a8
002bf8e8 7585eccb firefox!wmainCRTStartup+0xf
002bf8f4 7731d24d kernel32!BaseThreadInitThunk+0xe
002bf934 7731d45f ntdll!__RtlUserThreadStart+0x23
002bf94c 00000000 ntdll!_RtlUserThreadStart+0x1b

Comment 24

[chris hofmann]

(In reply to comment #22)
> If this helps, the crash report I get from Martijn's testcase is
> http://crash-stats.mozilla.com/report/index/bp-788b2166-695a-4182-8bbf-637fe2091106.
> The crash I get when I click the Add New Button widget with Google toolbar is
> http://crash-stats.mozilla.com/report/index/bp-1e904f8e-9ee2-4866-916e-9d52c2091106.
> I am using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b2pre)
> Gecko/20091106 Namoroka/3.6b2pre GTB6 (.NET CLR 3.5.30729) to reproduce.
> 
> Currently this stack is the #4 top crash for Firefox 3.6b1. Perhaps more
> crashes correlate to the popularity of the Google Toolbar?


http://people.mozilla.com/crash_analysis/20091109/20091109_Firefox_3.6b1-interesting-addons.txt
says

 _purecall | nsWindow::Show(int)|No crash (379 crashes)
     94% (356/379) vs.   8% (1046/13234) {3112ca9c-de6d-4884-a869-9855de68056c} (Google Toolbar, https://addons.mozilla.org/addon/6249)
     52% (196/379) vs.  36% (4817/13234) {20a82645-c095-46ed-80e3-08825760534b} (Microsoft .NET Framework Assistant, http://www.windowsclient.net/)
     23% (87/379) vs.  12% (1637/13234) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)
      9% (33/379) vs.   2% (259/13234) {89506680-e3f4-484c-a2c0-ed711d481eda} (Firefox Showcase, https://addons.mozilla.org/addon/1810)
     11% (42/379) vs.   6% (793/13234) [e-mail] (Personas, https://addons.mozilla.org/addon/10900)

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK, can you add a comment explaining that the Show() can result in the window being closed and nsXULWindow::Destroy being called on this window, which sets mWindow to null, so we have to keep the widget alive here. Also this means that the rest of SetVisibility may be happening on a destroyed window; that may be OK, but I suggest for safety we detect that here and exit from the function early.
You should also add a comment to nsXULWindow::OnChromeLoaded where it calls SetVisibility to indicate that Destroy may have been called there (but it's OK because OnChromeLoaded doesn't do anything afterwards).

Comment 26

[Joe Drew (not getting mail)]

I want this fixed, but I maintain that it shouldn't block the release of 3.6 if it's not blocking any earlier releases.

Comment 27

[chris hofmann]

yes, it should block.  latest data says the crash was present in earlier releases but the volume is dramtically higher in 3.6b1

distribution of all versions where the nsWindow::Show crash was found on 20091109-crashdata.csv
 411 Firefox 3.6b1
   8 Firefox 3.5.5
   1 Firefox 3.6b3pre
   1 Firefox 3.5.4

it also doesn't appear to be crashing earlier 3.0.x releases.

Comment 28

[chris hofmann]

looks like we hit the explosion of crashes when 3.6b1 pulled in a pocket of users at around the 200k level

3.6b1
adus   #crashes   date signature version

 89k   43 20091101-crashdata.csv _purecall | nsWindow::Show(int) 3.6b1
123k   66 20091102-crashdata.csv _purecall | nsWindow::Show(int) 3.6b1
158k   74 20091103-crashdata.csv _purecall | nsWindow::Show(int) 3.6b1
180k   71 20091104-crashdata.csv _purecall | nsWindow::Show(int) 3.6b1
195k  144 20091105-crashdata.csv _purecall | nsWindow::Show(int) 3.6b1
213k  444 20091106-crashdata.csv _purecall | nsWindow::Show(int) 3.6b1
198k  436 20091107-crashdata.csv _purecall | nsWindow::Show(int) 3.6b1
209k  446 20091108-crashdata.csv _purecall | nsWindow::Show(int) 3.6b1
211k  411 20091109-crashdata.csv _purecall | nsWindow::Show(int) 3.6b1

Comment 29

[chris hofmann]

and it doesn't look like something external since 3.5.4/5 has low volume over the same time with its tens of millions of users now.

   5 20091101-crashdata.csv _purecall | nsWindow::Show(int) 3.5.4
   5 20091102-crashdata.csv _purecall | nsWindow::Show(int) 3.5.4
   7 20091103-crashdata.csv _purecall | nsWindow::Show(int) 3.5.4
   8 20091104-crashdata.csv _purecall | nsWindow::Show(int) 3.5.4
  11 20091105-crashdata.csv _purecall | nsWindow::Show(int) 3.5.4
   2 20091106-crashdata.csv _purecall | nsWindow::Show(int) 3.5.4
   3 20091107-crashdata.csv _purecall | nsWindow::Show(int) 3.5.4
   4 20091108-crashdata.csv _purecall | nsWindow::Show(int) 3.5.4
   1 20091109-crashdata.csv _purecall | nsWindow::Show(int) 3.5.4


   no reports for 11/1-11/4
   1 20091105-crashdata.csv _purecall | nsWindow::Show(int) 3.5.5
   6 20091107-crashdata.csv _purecall | nsWindow::Show(int) 3.5.5
   7 20091108-crashdata.csv _purecall | nsWindow::Show(int) 3.5.5
   7 20091109-crashdata.csv _purecall | nsWindow::Show(int) 3.5.5

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: patch v2

This is just Makoto-san's patch with the comments I asked for.

I decided not to add the early exit I asked for previously; the rest of the function looks pretty safe and taking the early exit might have risks of its own.

Comment 31

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We should get this landed ASAP.

Comment 32

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/dc39e856ea45

Comment 33

[Mike Beltzner [:beltzner, not reading bugmail]]

Blocking 1.9.2

Comment 34

[Makoto Kato [:m_kato]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6b7cc00f5e5d

Comment 35

[Marcia Knous [:marcia]]

I no longer crash with the test case or following the STR in Comment 16 using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b3pre) Gecko/20091113 Namoroka/3.6b3pre GTB6 (.NET CLR 3.5.30729) as well as the latest nightly on Windows 7. So I can verify this, but unfortunately users will not be able to open many of these Google Toolbar buttons since nothing happens when I click them (still better than crashing). I will file a separate bug on that. Adding verified keyword.