Bug 7274 – Assertion failure in TimerBase::checkHeapIndex() (Timer.cpp:199) !timerHeap->isEmpty()

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

ASSERTION FAILED: !timerHeap->isEmpty() (WebCore/platform/Timer.cpp:199 void WebCore::TimerBase::checkHeapIndex() const)

#0  0x01c26d20 in WebCore::TimerBase::checkHeapIndex (this=0x1438e3c0) at WebCore/platform/Timer.cpp:199
#1  0x01ada2c0 in WebCore::TimerBase::heapDecreaseKey (this=0x1438e3c0) at WebCore/platform/Timer.cpp:217
#2  0x01c277a4 in WebCore::TimerBase::heapPop (this=0x1438e3c0) at WebCore/platform/Timer.cpp:260
#3  0x01c27840 in WebCore::TimerBase::heapIncreaseKey (this=0x1438e3c0) at WebCore/platform/Timer.cpp:241
#4  0x01ada6bc in WebCore::TimerBase::setNextFireTime (this=0x1438e3c0, newTime=1140015679.7352819) at WebCore/platform/Timer.cpp:294
#5  0x01ada7f0 in WebCore::TimerBase::fireTimers (fireTime=1140015679.7352819, firingTimers=@0xbfffe4c0) at WebCore/platform/Timer.cpp:330
#6  0x01ada8c4 in WebCore::TimerBase::sharedTimerFired () at WebCore/platform/Timer.cpp:350
#7  0x01ad9d40 in WebCore::timerFired () at WebCore/platform/mac/SharedTimerMac.cpp:44
#8  0x90770aec in __CFRunLoopDoTimer ()

The  timer in question had an m_heapIndex of -1 and an oldTime of 2.1174059774237895e-203 in setNextFireTime. (newTime was 1140015679.7352819).

And another one:
ASSERTION FAILED: (*timerHeap)[m_heapIndex] == this (WebCore/platform/Timer.cpp:202 void WebCore::TimerBase::checkHeapIndex() const)

This time m_heapIndex was 0, timerHeap->size() was 4, but none of the timers in the heap was ==this. oldTime was 6.6921152619080891e-203 and newTime was 1140019944.457437.

Where are those oldTime values coming from?

[Darin Adler]

oldTime of 6.6921152619080891e-203 is completely bogus. We should never see a time like this. The value of oldTime is the old value of m_nextFireTime.

Memory smashing? I set a breakpoint on where m_nextFireTime is assigned a value and it was never assigned a non-zero value smaller than 100, yet it did end up having such a value.

The third symptom, again pointing in that direction, is crashing on calling a pure virtual function -- TimerBase::fired() --

(gdb) p *timer
$28 = {
  <Noncopyable> = {<No data fields>}, 
  members of TimerBase: 
  _vptr$TimerBase = 0x0, 
  m_nextFireTime = 2.2833798994238128e-314, 
  m_repeatInterval = 2.2893483626215314e-314, 
  m_heapIndex = 1
}

[Darin Adler]

_vptr$TimerBase = 0x0 means that this is not a good object -- that is a pointer to the vtable and should never be 0.

[Alexey Proskuryakov]

For me, this is easily reproducible with the following steps:
1. Go to http://www.squarefree.com/bookmarklets/webdevel.html
2. Click on "shell" - a new window appears
3. Press Cmd+W to close it

Repeat steps 2 and 3 a few times. Sometimes it's an assertion failure, sometimes a quit with "pure virtual method called/terminate called without an active exception".

[Darin Adler]

I'll look at this as soon as I can.

I think I figured this out: when a timer is fired in TimerBase::fireTimers it can cause not only itself -- but also a subsequent element in the firingTimers array -- to be deleted. I have observed this in the debugger.

Created attachment 6515 [details]
Proposed patch

I don't know how to make a layout test for this bug.

[Darin Adler]

Comment on attachment 6515 [details]
Proposed patch

All I can say is ... wow! Thanks. r=me

*** Bug 7307 has been marked as a duplicate of this bug. ***

*** Bug 7256 has been marked as a duplicate of this bug. ***

[Eric Seidel (no email)]

*** Bug 7292 has been marked as a duplicate of this bug. ***