Summary: | Assertion failure in TimerBase::checkHeapIndex() (Timer.cpp:199) !timerHeap->isEmpty() | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | mitz | ||||
Component: | WebKit Misc. | Assignee: | Darin Adler <darin> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Major | CC: | catfish.man, darin, dvirasoro, eric | ||||
Priority: | P2 | ||||||
Version: | 420+ | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
URL: | http://www.apple.com/itunes/1billion/ | ||||||
Attachments: |
|
Description
mitz
2006-02-15 07:37:52 PST
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? 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 } _vptr$TimerBase = 0x0 means that this is not a good object -- that is a pointer to the vtable and should never be 0. 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". 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.
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. *** *** Bug 7292 has been marked as a duplicate of this bug. *** |