688895 - crash nsXULPopupManager::ShowTooltipAtScreen

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is 
report bp-ddf32716-606e-4ad0-bf0f-0d8302110919 .
============================================================= 

Seen in the explosive report - https://crash-analysis.mozilla.com/rkaiser/2011-09-22/2011-09-22.firefox.6.explosiveness.html. High correlation to the FFX Babylon Toolbar. https://crash-stats.mozilla.com/report/list?signature=nsXULPopupManager%3A%3AShowTooltipAtScreen%28nsIContent*%2C%20nsIContent*%2C%20int%2C%20int%29.

Seen across all versions.

82% (80/97) vs.   7% (7631/114741) [e-mail]
19% (18/97) vs.   7% (7679/114741) [e-mail]
11% (11/97) vs.   0% (284/114741) [e-mail] (NetVideoHunter Video Downloader, https://addons.mozilla.org/addon/7447)
9% (9/97) vs.   2% (2197/114741) [e-mail] (IDM CC, https://addons.mozilla.org/addon/6973)
8% (8/97) vs.   1% (1341/114741) {c0c9a2c7-2e5c-4447-bc53-97718bc91e1b} (Easy YouTube Video Downloader, https://addons.mozilla.org/addon/10137)
6% (6/97) vs.   0% (412/114741) [e-mail]

Comment 1

[Scoobidiver (away)]

It's above #300 browser crasher in 10.0.2.

Here are the last correlations in 10.0.2:
  nsXULPopupManager::ShowTooltipAtScreen(nsIContent*, nsIContent*, int, int)|EXCEPTION_ACCESS_VIOLATION_READ (24 crashes)
     46% (11/24) vs.   0% (198/69688) [e-mail] (NetVideoHunter Video Downloader, https://addons.mozilla.org/addon/7447)
     21% (5/24) vs.   1% (973/69688) {EEE6C361-6118-11DC-9C72-001320C79847} (SweetIM toolbar)

Comment 2

[Scoobidiver (away)]

It's #69 top browser crasher in 13.0.1, #59 in 14.0b12, #67 in 15.0a2 and #87 in 16.0a1.
It's likely related to bug 754380.

It's correlated to FunMoods and Incredibar:
nsXULPopupManager::ShowTooltipAtScreen(nsIContent*, nsIContent*, int, int)|EXCEPTION_ACCESS_VIOLATION_READ (138 crashes)
     36% (49/138) vs.   3% (4910/188317) [e-mail]
     31% (43/138) vs.   2% (3640/188317) [e-mail]
     19% (26/138) vs.   2% (2982/188317) {336D0C35-8A85-403a-B9D2-65C292C39087}
     16% (22/138) vs.   0% (306/188317) [e-mail]

The stack trace looks like:
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsXULPopupManager::ShowTooltipAtScreen 	layout/xul/base/src/nsXULPopupManager.cpp:624
1 	xul.dll 	nsXULTooltipListener::LaunchTooltip 	layout/xul/base/src/nsXULTooltipListener.cpp:511
2 	xul.dll 	nsXULTooltipListener::ShowTooltip 	layout/xul/base/src/nsXULTooltipListener.cpp:407
3 	xul.dll 	nsXULTooltipListener::sTooltipCallback 	layout/xul/base/src/nsXULTooltipListener.cpp:705
4 	xul.dll 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:473
5 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:624
6 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:116
7 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:201
8 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:175
9 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:163
10 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:232
11 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:257
12 	xul.dll 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3787
13 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3864
14 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3940
15 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:100
16 	firefox.exe 	__tmainCRTStartup 	crtexe.c:552
17 	kernel32.dll 	BaseThreadInitThunk 	
18 	ntdll.dll 	__RtlUserThreadStart 	
19 	ntdll.dll 	_RtlUserThreadStart

Comment 3

[Andrew Quartey [:drexler]]

Attachment: patch

checks for the possibility of widget being null since GetRootWidget() might not initialize it.

Comment 4

[Timothy Nikkel (:tnikkel)]

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

I'm having a hard time finding a way for the root widget to be null. It would be nice to know how that happens. This might just move the crash somewhere else, but that might be helpful in figuring it out.

Comment 5

[Andrew Quartey [:drexler]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/fd49929ef463

Comment 6

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/fd49929ef463

Comment 7

[Scoobidiver (away)]

It exploded across all affected versions recently.
It's #27 top browser crasher in 16.0.1 and #8 in 17.0b3.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

Can we get a regression widow here and see what might have caused this explosion?

Comment 9

[Scoobidiver (away)]

(In reply to Lukas Blakk [:lsblakk] from comment #8)
> Can we get a regression widow here and see what might have caused this
> explosion?
It's not a regression in Firefox. It started yesterday according to some users (see http://www.geckozone.org/forum/viewtopic.php?f=5&t=108965, for one running anti-malware software has fixed the issue) and crash stats (see https://crash-analysis.mozilla.com/rkaiser/2012-10-25/2012-10-25.firefox.16.explosiveness.html).
The symptoms are a Firefox startup crash (bad! 16.0.2?) and the screen that becomes blurry.

It's probably caused by an ad campaign from various third-party add-ons (malware):
  nsXULPopupManager::ShowTooltipAtScreen(nsIContent*, nsIContent*, int, int)|EXCEPTION_ACCESS_VIOLATION_READ (2678 crashes)
     23% (608/2678) vs.   2% (3982/180707) [e-mail]
     25% (664/2678) vs.   6% (10231/180707) [e-mail]
     18% (473/2678) vs.   0% (875/180707) [e-mail]
     15% (390/2678) vs.   1% (2497/180707) {687578b9-7132-4a7a-80e4-30ee31099e03}
     14% (362/2678) vs.   2% (3678/180707) {336D0C35-8A85-403a-B9D2-65C292C39087}
     15% (394/2678) vs.   4% (6338/180707) [e-mail]
     18% (473/2678) vs.   7% (13475/180707) {635abd67-4fe9-1b23-4f01-e679fa7484c1} (Yahoo! Toolbar, https://addons.mozilla.org/addon/2032)
     11% (282/2678) vs.   1% (2370/180707) [e-mail]
     13% (346/2678) vs.   4% (7339/180707) [e-mail]
      8% (227/2678) vs.   0% (381/180707) [e-mail]
     12% (313/2678) vs.   4% (6549/180707) {EEE6C361-6118-11DC-9C72-001320C79847}
     12% (326/2678) vs.   5% (8666/180707) avg@toolbar
      7% (178/2678) vs.   0% (355/180707) [e-mail]
      7% (184/2678) vs.   1% (1320/180707) {bf7380fa-e3b4-4db2-af3e-9d8783a45bfc}
      7% (178/2678) vs.   1% (2096/180707) {99079a25-328f-4bd4-be04-00955acaa0a7}
      7% (175/2678) vs.   1% (2038/180707) [e-mail]
      6% (164/2678) vs.   1% (1358/180707) [e-mail]
      7% (182/2678) vs.   2% (2776/180707) [e-mail]

Comment 10

[Scoobidiver (away)]

The issue is so common that there's a dedicated SUMO article: https://support.mozilla.org/kb/firefox-opens-transparent-or-blank-window

Please uplift the patch to Beta.

Comment 11

[Timothy Nikkel (:tnikkel)]

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

[Approval Request Comment]
Bug caused by (feature/regressing bug #): not sure
User impact if declined: crashes
Testing completed (on m-c, etc.): been on nightly for quite a while
Risk to taking this patch (and alternatives if risky): it's a simple null check, very safe, if may just make us crash somewhere else
String or UUID changes made by this patch: none

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

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

Please land asap so that we can get this in tomorrow's Beta 4.

Comment 13

[Timothy Nikkel (:tnikkel)]

https://hg.mozilla.org/releases/mozilla-beta/rev/73df03c49a38

Comment 14

[u279076]

I'm seeing no crash reports in the last week with this signature. Can we mark this bug verified for Firefox 17 or is there something more we can test? I don't see steps or a testcase for this bug.