969923 - clearInterval inside setTimeout causes crash in Greasemonkey and Firefox 27/28

Status: RESOLVED DUPLICATE of bug 934509

(Firefox :: Extension Compatibility, defect)

Description

[Rob Wu [:robwu]]

Attachment: Load this script in Greasemonkey in Firefox 27 or 28, then visit example.com to trigger a crash.

When the following snippet is executed in the sandbox of a Greasemonkey script, Firefox crashes.

setTimeout(function() {
    clearTimeout();
});

I managed to reproduce the bug in Firefox 27 (XP) and Firefox 28 (Linux).

Steps to reproduce:

1. Install Firefox 27 or 28.
2. Install greasemonkey
3. Install the userscript-to-induce-crash.user.js (attachment)
4. Visit http://example.com/

This is the full back trace when I run Firefox through gdb:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe8ae7da4 in mozilla::LinkedListElement<nsTimeout>::getNext (this=0x0) at ../../dist/include/mozilla/LinkedList.h:161
161     ../../dist/include/mozilla/LinkedList.h: No such file or directory.
(gdb) bt f
#0  0x00007fffe8ae7da4 in mozilla::LinkedListElement<nsTimeout>::getNext (this=0x0) at ../../dist/include/mozilla/LinkedList.h:161
No locals.
#1  0x00007fffe8b167a1 in nsGlobalWindow::RunTimeout (this=0x618000186880, aTimeout=0x60c000000000) at /builds/slave/m-beta-l64-asan-d-000000000000/build/dom/base/nsGlobalWindow.cpp:11916
        timeout = <optimized out>
        firingDepth = 1
        last_expired_timeout = <optimized out>
        last_insertion_point = 0x0
        nextTimeout = <optimized out>
#2  0x00007fffe8b2b5ee in nsGlobalWindow::TimerCallback (aTimer=<optimized out>, aClosure=<optimized out>) at /builds/slave/m-beta-l64-asan-d-000000000000/build/dom/base/nsGlobalWindow.cpp:12193
No locals.
#3  0x00007fffe6b965a7 in nsTimerImpl::Fire (this=0x6080000f3a20) at /builds/slave/m-beta-l64-asan-d-000000000000/build/xpcom/threads/nsTimerImpl.cpp:551
No locals.
#4  0x00007fffe6b96def in nsTimerEvent::Run (this=<optimized out>) at /builds/slave/m-beta-l64-asan-d-000000000000/build/xpcom/threads/nsTimerImpl.cpp:635
No locals.
#5  0x00007fffe6b8d0c4 in nsThread::ProcessNextEvent (this=0x611000018280, mayWait=false, result=<optimized out>) at /builds/slave/m-beta-l64-asan-d-000000000000/build/xpcom/threads/nsThread.cpp:612
No locals.
#6  0x00007fffe6a765a7 in NS_ProcessNextEvent (thread=<optimized out>, mayWait=false) at /builds/slave/m-beta-l64-asan-d-000000000000/build/xpcom/glue/nsThreadUtils.cpp:263
No locals.
#7  0x00007fffe72a2fa8 in mozilla::ipc::MessagePump::Run (this=0x6060000ba2d8, aDelegate=0x61400000dc40) at /builds/slave/m-beta-l64-asan-d-000000000000/build/ipc/glue/MessagePump.cpp:85
No locals.
#8  0x00007fffe72194b1 in MessageLoop::RunInternal (this=0x61400000dc40) at /builds/slave/m-beta-l64-asan-d-000000000000/build/ipc/chromium/src/base/message_loop.cc:222
No locals.
#9  0x00007fffe72192b5 in MessageLoop::Run (this=0x61400000dc40) at /builds/slave/m-beta-l64-asan-d-000000000000/build/ipc/chromium/src/base/message_loop.cc:189
No locals.
#10 0x00007fffe88211d1 in nsBaseAppShell::Run (this=<optimized out>) at /builds/slave/m-beta-l64-asan-d-000000000000/build/widget/xpwidgets/nsBaseAppShell.cpp:161
        thread = 0x611000018280
#11 0x00007fffea990fba in nsAppStartup::Run (this=0x60700002ec40) at /builds/slave/m-beta-l64-asan-d-000000000000/build/toolkit/components/startup/nsAppStartup.cpp:276
        rv = <optimized out>
        retval = <optimized out>
#12 0x00007fffea807a2c in XREMain::XRE_mainRun (this=<optimized out>) at /builds/slave/m-beta-l64-asan-d-000000000000/build/toolkit/xre/nsAppRunner.cpp:4008
        rv = <optimized out>
#13 0x00007fffea808c69 in XREMain::XRE_main (this=0x7fffffffc200, argc=<optimized out>, argv=<optimized out>, aAppData=<optimized out>) at /builds/slave/m-beta-l64-asan-d-000000000000/build/toolkit/xre/nsAppRunner.cpp:4076
        rv = <optimized out>
        result = <optimized out>
        appInitiatedRestart = <error reading variable appInitiatedRestart (Cannot access memory at address 0x0)>
#14 0x00007fffea8095d6 in XRE_main (argc=-21728, argv=0x61900001f480, aAppData=0x7fffef634990 <vtable for nsGlobalWindow+2864>, aFlags=<optimized out>)
    at /builds/slave/m-beta-l64-asan-d-000000000000/build/toolkit/xre/nsAppRunner.cpp:4316
        result = <optimized out>
#15 0x000000000045a0f6 in do_main (argc=<optimized out>, argv=<optimized out>, xreDirectory=0x610000007440) at /builds/slave/m-beta-l64-asan-d-000000000000/build/browser/app/nsBrowserApp.cpp:280
        appDataFile = <optimized out>
        rv = <optimized out>
#16 0x0000000000459668 in main (argc=4, argv=0x7fffffffdb58) at /builds/slave/m-beta-l64-asan-d-000000000000/build/browser/app/nsBrowserApp.cpp:648
        start = <optimized out>
        rv = <optimized out>
        result = <optimized out>

Comment 1

[Rob Wu [:robwu]]

Link to issue on Greasemonkey's bug tracker: https://github.com/greasemonkey/greasemonkey/issues/1869

Comment 2

[Alice0775 White]

This seemed to be fixed in Nightly30.0a1.

Progression window(m-i)
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b2670ddc0c97
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140207053101
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bf640fe76500
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140207055301
Progression pushlog;
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b2670ddc0c97&tochange=bf640fe76500

Fixed by:
bf640fe76500	Boris Zbarsky — Bug 934509. Make sure to not accidentally pass 0 to ClearTimeoutOrInterval, even if someone calls clearInterval(0) on an Xray for a Window. r=peterv

Comment 3

[Boris Zbarsky [:bzbarsky]]

Argh.  Yes, and this bug had the _exact_ steps to reproduce that would have made fixing bug 934509 trivial.  Wish it had gotten filed in Core.  :(

Comment 4

[Rob Wu [:robwu]]

Will it be merged back into

Comment 5

[Boris Zbarsky [:bzbarsky]]

That's the idea, yes.  See the approval requests in bug 934509.

Comment 6

[Robert Kaiser]

(In reply to Boris Zbarsky [:bz] from comment #3)
> Argh.  Yes, and this bug had the _exact_ steps to reproduce that would have
> made fixing bug 934509 trivial.  Wish it had gotten filed in Core.  :(

Well, this bug only was filed almost two days after you had attached the fix to the other bug already, so this case wouldn't have helped you as it came in too late.

That said, does this make up a test case we should be running?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> filed almost two days after you had attached the fix

Oh, I misread the date...

> That said, does this make up a test case we should be running?

Probably...  it'll become irrelevant-ish once bug 789261 is fixed.