Tracy Walker [:tracy] Reporter
	Description • 11 years ago

This bug was filed from the Socorro interface and is 
report bp-3a4c2063-91c7-48f5-aeae-8419f2131103.
=============================================================

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsGlobalWindow::RunTimeout(nsTimeout *) 	dom/base/nsGlobalWindow.cpp
1 	xul.dll 	nsGlobalWindow::TimerCallback(nsITimer *,void *) 	dom/base/nsGlobalWindow.cpp
2 	xul.dll 	nsTimerImpl::Fire() 	xpcom/threads/nsTimerImpl.cpp
3 	xul.dll 	nsTimerEvent::Run() 	xpcom/threads/nsTimerImpl.cpp
4 	xul.dll 	nsThread::ProcessNextEvent(bool,bool *) 	xpcom/threads/nsThread.cpp
5 	xul.dll 	nsRefPtr<XPCWrappedNative>::~nsRefPtr<XPCWrappedNative>() 	obj-firefox/dist/include/nsAutoPtr.h
6 	nss3.dll 	PR_Unlock 	nsprpub/pr/src/threads/combined/prulock.c
7 	xul.dll 	NS_ProcessNextEvent(nsIThread *,bool) 	xpcom/glue/nsThreadUtils.cpp
8 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate *) 	ipc/glue/MessagePump.cpp
9 	xul.dll 	xul.dll@0x127cd58 	
10 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc
11 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
12 	xul.dll 	nsBaseAppShell::Run() 	widget/xpwidgets/nsBaseAppShell.cpp
13 	xul.dll 	nsAppShell::Run() 	widget/windows/nsAppShell.cpp
14 	nss3.dll 	nss3.dll@0x79a0 	
15 	xul.dll 	XREMain::XRE_main(int,char * * const,nsXREAppData const *) 	toolkit/xre/nsAppRunner.cpp
16 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp
17 	firefox.exe 	do_main 	browser/app/nsBrowserApp.cpp
18 	firefox.exe 	NS_internal_main(int,char * *) 	browser/app/nsBrowserApp.cpp
19 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp
20 	firefox.exe 	__tmainCRTStartup 	f:/dd/vctools/crt_bld/self_x86/crt/src/crtexe.c
21 	kernel32.dll 	kernel32.dll@0x1336a 	
22 	ntdll.dll 	ntdll.dll@0x39f72 	
23 	ntdll.dll 	ntdll.dll@0x39f45

started occurring 10/28 on Aurora http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=52f24889dccc&tochange=7090e4028a66
and 
10/29 on Nightly http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4646259ab62d&tochange=518f5bff0ae4

	Benjamin Smedberg
	Comment 1 • 11 years ago

https://crash-analysis.mozilla.com/bsmedberg/bug934509-nightly.csv
  regression appeared on buildid 20131028
https://crash-analysis.mozilla.com/bsmedberg/bug934509-aurora.csv
  3 hits on 20131029 but didn't appear "for real" until 20131101

I would look in the nightly regression range from the 27th-28th

	silverwind
	Comment 2 • 11 years ago

I'm plagued by this crash right now in Win7 and Linux too, which happens randomly (even on chrome pages), if you need any info.

	Robert Kaiser
	Comment 3 • 11 years ago

This is topcrash #11 on Aurora right now as seems to clearly be a 27 regression.

	Dapeng Wei
	Comment 4 • 11 years ago

I use Nightly 28.0a1.
When I visit Google Calendar and other Google sites(except GMail and Google search),Firefox crash!
It can be reproduced.
https://crash-stats.mozilla.com/report/index/071b1574-d005-4ee4-bcbe-15dc02131121

	Tracy Walker [:tracy] Reporter
	Comment 5 • 11 years ago

Dapeng Wei, can you share when it crashes, is it upon login to gmail properties or some other action?

Please provide the steps you use to reproduce, thanks.

	Dapeng Wei
	Comment 6 • 11 years ago

(In reply to [:tracy] Tracy Walker - QA Mentor from comment #5)
> Dapeng Wei, can you share when it crashes, is it upon login to gmail
> properties or some other action?
> 
> Please provide the steps you use to reproduce, thanks.
First,I login my Google account in Gmail.
Second,I open Google calender or Google accounts website,the Firefox crash.
It also crashes on my macbook.Thanks.
https://crash-stats.mozilla.com/report/index/d5b6feb6-b45e-44d7-bf41-7e36d2131121

	Theodoor
	Comment 7 • 11 years ago

Steps:
Install Greasemonkey, 
Install YouTube Lyrics by Rob W(http://userscripts.org/scripts/show/112070)
Open Grooveshark

	silverwind
	Comment 8 • 11 years ago

Maybe it's Greasemonkey related? I can't really provide any steps as my crashes are just happening randomly.

	Dapeng Wei
	Comment 9 • 11 years ago

(In reply to [:tracy] Tracy Walker - QA Mentor from comment #5)
> Dapeng Wei, can you share when it crashes, is it upon login to gmail
> properties or some other action?
> 
> Please provide the steps you use to reproduce, thanks.

I reproduced this crash on Mac and windows.
It related on Greasemonkey.
First,Firefox Nightly 28.0a1 install Greasemonkey 1.12 and this script（http://userscripts.org/scripts/show/159750）
Second,I open Google calender or Google accounts website,the Firefox crash.
Thanks.

	Deathamns
	Comment 10 • 11 years ago

Hi,
The crash happens on this specific piece of JavaScript:
clearInterval(v); // where "v" is null

However, it doesn't crash in every case, for example if you simply run "clearInterval(null);" in the Console (F12) on a webpage, then nothing will happen. Probably other conditions must be met.
Also, bypassing the crash is simple as that:
if (v) clearInterval(v);

Here is an extension that I develop, and which suffered from this crash:
https://files.myopera.com/Deathamns/extension/imagus/archive/firefox/imagus-0.9.7.xpi

To reproduce the crash (after the extension is installed and enabled):
- Open a new tab and load an image in it, for example: https://i.imgur.com/CV1QTXz.jpg
- At first time nothing should happen, the image normally loads, and the extension features should work, because at first "v" has a value returned by setInterval() (it runs a function that checks if the image is available, testing if the width property of the image isn't 0).
- Hit F5, which now should read the image from cache (if the image was already in your cache, maybe you had a crash already), and because of that the width is immediately available for the script, and it won't invoke the setInterval() for checking, but this leaves the "v" with its default null value (that I set earlier), and that will be passed to the clearInterval(), and the browser will crash.

My first report was made from (probably the build where the crash was introduced):
Product Firefox
Version 27.0a1
Build ID 20131028030205

	u279076
	Comment 11 • 11 years ago

7 Day Ranking:
> Firefox 26: N/A
> Firefox 27: #7 @ 0.17% (down 6 positions)
> Firefox 28: #23 @ 0.66% (down 2 positions)
> Firefox 29: #21 @ 0.55% (down 1 position)

Looks like this is still a top-crash (at least on Beta) but it appears to be dropping.

	Robert Kaiser
	Comment 12 • 11 years ago

Right now (7-day):

Firefox 26: N/A
Firefox 27: #39 @ 0.26%
Firefox 28: #20 @ 0.70%
Firefox 29: #14 @ 0.78%

Also, 26.0 isn't completely unaffected, but at very low rate - the signature summary at https://crash-stats.mozilla.com/report/list?signature=nsGlobalWindow%3A%3ARunTimeout%28nsTimeout%2A%29 says that it exists in a lot of versions.

	u279076
	Comment 13 • 11 years ago

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #12)
> Right now (7-day):
> 
> Firefox 26: N/A
> Firefox 27: #39 @ 0.26%
> Firefox 28: #20 @ 0.70%
> Firefox 29: #14 @ 0.78%

This no longer qualifies as a top-crash.

	bhavana bajaj [:bajaj]
	Comment 14 • 11 years ago

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #13)
> (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #12)
> > Right now (7-day):
> > 
> > Firefox 26: N/A
> > Firefox 27: #39 @ 0.26%
> > Firefox 28: #20 @ 0.70%
> > Firefox 29: #14 @ 0.78%
> 
> This no longer qualifies as a top-crash.

Given this, removing from release tracking here.

	Robert Kaiser
	Comment 15 • 10 years ago

This is the #1 topcrash in the starting days of 27 release now.

Correlations:

64% (140/218) vs.   2% (773/47794) {e4a8a97b-f2ed-450b-b12d-ee082ba24781} (Greasemonkey, https://addons.mozilla.org/addon/748)
24% (52/218) vs.   0% (95/47794) scriptish@erikvold.com
23% (50/218) vs.   8% (3653/47794) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)
11% (25/218) vs.   0% (234/47794) helper@savefrom.net
9% (20/218) vs.   1% (419/47794) feca4b87-3be4-43da-a1b1-137c24220968@jetpack
8% (18/218) vs.   1% (292/47794) elemhidehelper@adblockplus.org (Adblock Plus: Element Hiding Helper, https://addons.mozilla.org/addon/4364)
6% (14/218) vs.   0% (29/47794) memoryrestart@teamextension.com
7% (15/218) vs.   1% (311/47794) {46551EC9-40F0-4e47-8E18-8E5CF550CFB8} (Stylish, https://addons.mozilla.org/addon/2108)
6% (13/218) vs.   0% (59/47794) multifox@hultmann
9% (20/218) vs.   3% (1658/47794) {b9db16a4-6edc-47ec-a1f4-b86292ed211d} (Video DownloadHelper, https://addons.mozilla.org/addon/3006)

So, as earlier comments suspected, Greasemonkey makes this more likely, but there's other add-ons that help trigger this as well - anything noteworthy those have in common?

	Benjamin Smedberg
	Comment 16 • 10 years ago

The correct regression range from comment 1 was:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a80dce1126db&tochange=4646259ab62d

It seems pretty clear to me that this is a regression from https://hg.mozilla.org/mozilla-central/rev/508288a2b62c bug 918345 which is quickstubbing "window" and landed right before the 27 train left.

The crash is here: http://hg.mozilla.org/releases/mozilla-release/annotate/b8896fee530d/dom/base/nsGlobalWindow.cpp#l11813 at crash address 0x0

So it seems that previously the timeout linked list would always hit the dummy timeout before it hit null, but now that's not true. peterv/bz do you know what might be going on here? Nested event loops resetting the dummy timer position, maybe?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 17 • 10 years ago

The steps in comment 10 don't reproduce the bug for me on trunk or when I build from rev 508288a2b62c, but the steps in comment 9 do.

clearInterval(null) is a no-op both before and after the changes in bug 918345, or at least should be.

I tried disabling the quickstubs entirely on trunk, and I still get the crash, but it's possible that the C++ changes involved broke something.  Looking into what that might be...

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 18 • 10 years ago

Oh, and I've confirmed via local builds that the crash I'm seeing with the comment 9 steps is in fact caused by bug 918345.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 19 • 10 years ago

> or at least should be.

Emphasis on _should_!  Deathamns, you were spot on, this is a clearInterval(0) problem.

Specifically, the nsTimeout constructor sets mPublicId(0).  Then nsGlobalWindow::SetTimeoutOrInterval sets mPublicId to the next sequence number before returning.

nsGlobalWindow::ClearTimeoutOrInterval walks the list of timeouts looking for the one whose mPublicId matches the argument and if it's not running removes it from the timeout list.

The callers of ClearTimeoutOrInterval are supposed to make sure that 0 doesn't get passed to it, but the XPCOM version of ClearInterval lost that check in bug 918345.  So now if you're in the middle of running timeouts on a content window and chrome calls clearInterval that content window (so you get Xrays, which are still calling the XPCOM ClearInterval for now) and passes 0 or something that coerces to 0 (null, undefined, "0", etc), we will helpfully remove dummy_timeout from the list.  After that, you get the observed crash.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 21 • 10 years ago

That patch applies cleanly to 27, 28, 29 as well.

Deathamns, Dapeng Wei, Theodoor, thank you all for steps to reproduce for this.  Having a way to reproduce made it much simpler to sort this out.

And Benjamin, thank you for pointing to the right place to look!

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 22 • 10 years ago

Comment on attachment 8372043 [details] [diff] [review]
This fixes the comment 9 steps to reproduce for me on trunk

[Approval Request Comment]
Regression caused by (bug #): Bug 918345 
User impact if declined: The crashes will continue until morale improves.
Testing completed (on m-c, etc.): Locally tested to fix the crash I could
   reproduce.
Risk to taking this patch (and alternatives if risky):  Very very low risk.
String or IDL/UUID changes made by this patch:  None

Do I need to request approval-mozilla-b2g28 on this too?

	Peter Van der Beken [:peterv]
	Comment 23 • 10 years ago

Comment on attachment 8372043 [details] [diff] [review]
This fixes the comment 9 steps to reproduce for me on trunk

Review of attachment 8372043 [details] [diff] [review]:
-----------------------------------------------------------------

Grmbl.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 24 • 10 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/bf640fe76500

	Ryan VanderMeulen [:RyanVM]
	Comment 25 • 10 years ago

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

	Sylvestre Ledru [:Sylvestre]
	Comment 26 • 10 years ago

Comment on attachment 8372043 [details] [diff] [review]
This fixes the comment 9 steps to reproduce for me on trunk

Uplift accepted for aurora + beta.

	Ryan VanderMeulen [:RyanVM]
	Comment 27 • 10 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/358ca4ea3b30
https://hg.mozilla.org/releases/mozilla-beta/rev/959db82272fe

(In reply to Boris Zbarsky [:bz] from comment #22)
> Do I need to request approval-mozilla-b2g28 on this too?

No.
https://wiki.mozilla.org/Release_Management/B2G_Landing#Landing_Procedure_4

	Anthony Lieuallen
	Comment 29 • 10 years ago

Multiple Greasemonkey users have reported crashes.  Sorry I don't understand Mozilla's terminology and buganizer fields better but:

Can you explain in plain English when exactly this bug will be fixed in Firefox?  Should I try to rush a patch into Greasemonkey to get it to work around the bug?

	Benjamin Smedberg
	Comment 30 • 10 years ago

I don't think that release management has decided whether to do a dot-release of Firefox 27 for this issue. Setting NI? to clarify.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 31 • 10 years ago

Anthony, this will definitely be fixed in Firefox 28.  As comment 30 says, whether it'll be fixed before that is unclear.

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 32 • 10 years ago

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #30)
> I don't think that release management has decided whether to do a
> dot-release of Firefox 27 for this issue. Setting NI? to clarify.

At this point we still do not have a driver for a dot release or a chemspill. As mentioned, this is fixed in FF28 which will release in 5 weeks so if there is a workaround that would help users impacted by this over that time period, that would be ideal.

	Ryan VanderMeulen [:RyanVM]
	Comment 33 • 10 years ago

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/959db82272fe

	Paul Silaghi, QA [:pauly]
	Comment 34 • 10 years ago

Reproduced in Nightly 2013-11-26 using the STR in comment 9.
Verified fixed FF 30.0a1(2014-02-10), Win 7 x64.

	Bogdan Maris, Desktop QA
	Comment 35 • 10 years ago

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:28.0) Gecko/20100101 Firefox/28.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Mozilla/5.0 (X11; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0

Reproduced the initial crash on Nightly 2014-02-04 using STR from comment 9. Verified as fixed on Firefox 28 beta 1 and latest Aurora 29.0a2 (buildID: 20140211004037).

	Ryan VanderMeulen [:RyanVM]
	Comment 36 • 10 years ago

Can we somehow test this?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 37 • 10 years ago

See bug 969923 comemnt 7.

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 38 • 10 years ago

Anthony, do you have a possible workaround that you can land in GM until FF28 is released?

	Anthony Lieuallen
	Comment 39 • 10 years ago

I believe we can inject a clearInterval method into the sandbox, which wraps a private reference to the real clearInterval, and passes the call along only when the argument is non-falsy.

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 40 • 10 years ago

(In reply to Anthony Lieuallen from comment #39)
> I believe we can inject a clearInterval method into the sandbox, which wraps
> a private reference to the real clearInterval, and passes the call along
> only when the argument is non-falsy.

We can certainly QA this if you have a patched version available.

	u279076
	Comment 41 • 10 years ago

(In reply to Lukas Blakk [:lsblakk] from comment #40)
> (In reply to Anthony Lieuallen from comment #39)
> > I believe we can inject a clearInterval method into the sandbox, which wraps
> > a private reference to the real clearInterval, and passes the call along
> > only when the argument is non-falsy.
> 
> We can certainly QA this if you have a patched version available.

Can we? I'm not sure how we could test this without a PoC and if we had one it'd be easier to just check that into a testsuite.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 42 • 10 years ago

Anthony, comment 9 has steps to reproduce with greasemonkey.

If you just want a PoC not involving greasemonkey, run this in a browser scratchpad in a build without the fix:

  content.setTimeout(function() { content.clearInterval(0); }, 0)

but that won't tell you anything about whether Greasemonkey has shipped a workaround for this, of course.

	Anthony Lieuallen
	Comment 43 • 10 years ago

Workaround patch:
https://github.com/greasemonkey/greasemonkey/commit/24f9860628536f897fb00b5a9eea5ea032c36982

Reproduce script:
https://gist.github.com/arantius/8943384

Install this script into anything up to Greasemonkey 1.15beta1 in Firefox 27 (click on the "raw" link) and confirm the "Crash?" dialog, and Firefox will crash.  Just built 1.15beta2:
https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/versions/#version-1.15beta2
Which contains the workaround patch.

If you can confirm the fix (works for me), I can push a non-beta build.

	u279076
	Comment 44 • 10 years ago

Using Firefox 27.0 and Greasemonkey 1.15beta1 I get the Crash? alert and a subsequent crash after loading accounts.google.com. After updating to Greasemonkey 1.15beta2 I do not get the Crash? alert on accounts.google.com.

	Anthony Lieuallen
	Comment 45 • 10 years ago

Odd.  It (the prompt) should show up at all pages, and definitely does for me at https://accounts.google.com/ServiceLogin .  What do you observe at other pages?  I.e. http://www.example.com/ ?

	u279076
	Comment 46 • 10 years ago

(In reply to Anthony Lieuallen from comment #45)

> https://accounts.google.com/ServiceLogin
With GM 1.15beta2 nothing shows.

> http://www.example.com/
With GM 1.15beta2 nothing shows.

	Anthony Lieuallen
	Comment 47 • 10 years ago

I just set up a new fresh Firefox profile, installed 1.15beta2 into Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0, added the linked script, and I totally get the "Crash?" prompt at both pages.

Do you get any errors logged to any console that look related?

	Benjamin Smedberg
	Comment 48 • 10 years ago

Of the crashes with this signature in the past 7 days, 3967 of them have Greasemonkey installed and 1747 of them don't. This means to me that we're seeing this with web content also and whether or not Greasemonkey takes a workaround we should also spin a fixed build for users.

	u279076
	Comment 49 • 10 years ago

This works now on a clean profile following these steps:
1. Start Firefox 27.0 with a new profile
2. Install https://addons.mozilla.org/firefox/downloads/file/241259/greasemonkey-1.15beta1-fx.xpi?src=version-history
3. Restart Firefox
4. Load https://gist.github.com/arantius/8943384/raw/9db2349ffe1cdc172ba237fdbbe7635086f1571f/gm1869.user.js
5. Click Install on the installation dialog and OK on the doorhanger
6. Load https://accounts.google.com/ServiceLogin
> Crash? alert appears
7. Click OK
> "The page at https://accounts.youtube.com says: Crash?" alert appears
8. Click OK
> Crash (expected)
9. Restart Firefox
> Session restored with Crash? dialog
10. Click cancel 
> "The page at https://accounts.youtube.com says: Crash?" alert appears
11. Click cancel
> No crash
12. Install https://addons.mozilla.org/firefox/downloads/file/243206/greasemonkey-1.15beta2-fx.xpi?src=version-history
13. Restart Firefox
> Crash? alert appears
14. Click OK
> "The page at https://accounts.youtube.com says: Crash?" alert appears
15. Click OK
> No crash


I'm not sure why it isn't failing for me anymore as indicated in comment 46 but it works every time I try this now.

	Anthony Lieuallen
	Comment 50 • 10 years ago

Ok I've pushed 1.15 final out.  I'd appreciate a quick review.

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 51 • 10 years ago

Comment on attachment 8372043 [details] [diff] [review]
This fixes the comment 9 steps to reproduce for me on trunk

We're going to take this on for a 27.0.1 to be released later this week when we unthrottle uptake for FF27 so please go ahead and land on m-r branch.

	Ryan VanderMeulen [:RyanVM]
	Comment 52 • 10 years ago

https://hg.mozilla.org/releases/mozilla-release/rev/4c0f8398756a

	Catalin Varga [QA][:VarCat]
	Comment 53 • 10 years ago

I reproduce the crash using the first 6 steps from comment 49 on Mac OS X 10.8.5 and Win 7 x64
Using the FF 27 release.

The bug was verified using the following environment:

FF 27.0.1 
Build Id : 20140212131424
OS: Win 7 x64, Mac Os x 10.8.5 and Ubuntu 12.04 x32