Closed Bug 1310925 Opened 5 years ago Closed 5 years ago

Crash in TimerThread::PostTimerEvent

Categories

(Core :: XPCOM, defect)

Unspecified
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: ting, Assigned: bwc)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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.
  {
    // 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.
I can't see how it is safe to access nsTimerImpl::mEventTarget without synchronization.
Assignee: nobody → docfaraday
I am just wondering do we still need to enqueue the nsTimerEvent in this case?
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 on attachment 8802687 [details]
Bug 1310925: Acquire a reference before unlocking, just in case.

https://reviewboard.mozilla.org/r/87012/#review86372
Attachment #8802687 - Flags: review?(nfroyd) → review+
Pushed by bcampen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/19500dd560b1
Acquire a reference before unlocking, just in case. r=froydnj
https://hg.mozilla.org/mozilla-central/rev/19500dd560b1
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
You need to log in before you can comment on or make changes to this bug.