1310925 - Crash in TimerThread::PostTimerEvent

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Ting-Yu Chou [:ting] (away)]

This bug was filed from the Socorro interface and is 
report bp-8a0cb469-bc7d-490c-b34e-f781a2161018.
=============================================================
#32 of Nightly 20161016030205 on Windows, 4 crashes from 4 installations.

Comment 1

[Ting-Yu Chou [:ting] (away)]

  {
    // We release mMonitor around the Dispatch because if this timer is targeted
    // at the TimerThread we'll deadlock.
    MonitorAutoUnlock unlock(mMonitor);
00007FFD46D3E1A0  mov         rcx,qword ptr [r14+28h]
00007FFD46D3E1A4  call        qword ptr [__imp_PR_Unlock (07FFD48FBEB38h)]
    rv = target->Dispatch(event, NS_DISPATCH_NORMAL);
00007FFD46D3E1AA  mov         rdx,rdi
00007FFD46D3E1AD  lea         rcx,[rbp-30h]
00007FFD46D3E1B1  call        RefPtr<`anonymous namespace'::AsyncGetBookmarksForURI<void (__cdecl nsNavBookmarks::*)(mozilla::places::ItemChangeData const & __ptr64) __ptr64,mozilla::places::ItemChangeData> >::RefPtr<`anonymous namespace'::AsyncGetBookmarksForURI<void (__cdecl nsNavBookmarks::*)(mozilla::places::ItemChangeData const & __ptr64) __ptr64,mozilla::places::ItemChangeData> > (07FFD46A798A8h)
00007FFD46D3E1B6  xor         r8d,r8d
00007FFD46D3E1B9  mov         rcx,r15
00007FFD46D3E1BC  mov         rdx,qword ptr [rax]
00007FFD46D3E1BF  mov         qword ptr [rax],r12
00007FFD46D3E1C2  mov         rax,qword ptr [r15]
00007FFD46D3E1C5  mov         qword ptr [rbp+58h],rdx
00007FFD46D3E1C9  lea         rdx,[rbp+58h]
00007FFD46D3E1CD  call        qword ptr [rax+18h]  // crash, rax = *target = 0xe5e5e5e5e5e5e5e5

So for some reasons the target has been freed.

Comment 2

[JW Wang [:jwwang] [:jw_wang]]

I can't see how it is safe to access nsTimerImpl::mEventTarget without synchronization.

Comment 3

[Byron Campen [:bwc]]

Attachment: Bug 1310925: Acquire a reference before unlocking, just in case.

Review commit: https://reviewboard.mozilla.org/r/87012/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/87012/

Comment 4

[Ting-Yu Chou [:ting] (away)]

I am just wondering do we still need to enqueue the nsTimerEvent in this case?

Comment 5

[Byron Campen [:bwc]]

You mean if the nsTimerImpl is Neutered after we unlock the mutex, but before we dispatch? Strictly speaking, no, but we'd need to lock around the Dispatch to prevent this from happening, and even if we did, the timer could still be Neutered while the event was waiting in the queue.

Comment 6

[Nathan Froyd [:froydnj]]

Comment on attachment 8802687 [details]
Bug 1310925: Acquire a reference before unlocking, just in case.

https://reviewboard.mozilla.org/r/87012/#review86372

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/19500dd560b1
Acquire a reference before unlocking, just in case. r=froydnj

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/19500dd560b1