7274 2006-02-15 07:37:52 -0800 Assertion failure in TimerBase::checkHeapIndex() (Timer.cpp:199) !timerHeap->isEmpty() 2006-02-20 10:19:52 -0800 1 1 1 Unclassified WebKit WebKit Misc. 420+ Mac OS X 10.4 RESOLVED FIXED http://www.apple.com/itunes/1billion/ P2 Major --- 1 mitz darin catfish.man darin dvirasoro eric oldest_to_newest 32703 0 mitz 2006-02-15 07:37:52 -0800 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). 32707 1 mitz 2006-02-15 08:30:18 -0800 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? 32722 2 darin 2006-02-15 10:15:05 -0800 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. 32723 3 mitz 2006-02-15 10:21:42 -0800 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 } 32724 4 darin 2006-02-15 10:29:22 -0800 _vptr$TimerBase = 0x0 means that this is not a good object -- that is a pointer to the vtable and should never be 0. 32745 5 ap 2006-02-15 13:22:15 -0800 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". 32749 6 darin 2006-02-15 13:31:52 -0800 I'll look at this as soon as I can. 32808 7 mitz 2006-02-15 15:36:17 -0800 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. 32816 8 6515 mitz 2006-02-15 15:59:17 -0800 Created attachment 6515 Proposed patch I don't know how to make a layout test for this bug. 32846 9 6515 darin 2006-02-15 16:36:51 -0800 Comment on attachment 6515 Proposed patch All I can say is ... wow! Thanks. r=me 33069 10 mitz 2006-02-16 14:52:11 -0800 *** Bug 7307 has been marked as a duplicate of this bug. *** 33256 11 mitz 2006-02-18 09:52:58 -0800 *** Bug 7256 has been marked as a duplicate of this bug. *** 33506 12 eric 2006-02-20 10:19:52 -0800 *** Bug 7292 has been marked as a duplicate of this bug. *** 6515 2006-02-15 15:59:17 -0800 2006-02-15 16:36:51 -0800 Proposed patch 7274_r1.patch text/plain 1256 mitz SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiAxMjgzNSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTQgQEAKKzIwMDYtMDItIyMgIE1pdHogUGV0dGVsICA8b3BlbmRhcndpbi5vcmdA bWl0enBldHRlbC5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisK KyAgICAgICAgLSBmaXggaHR0cDovL2J1Z3ppbGxhLm9wZW5kYXJ3aW4ub3JnL3Nob3dfYnVnLmNn aT9pZD03Mjc0CisgICAgICAgICAgQXNzZXJ0aW9uIGZhaWx1cmUgaW4gVGltZXJCYXNlOjpjaGVj a0hlYXBJbmRleCgpIChUaW1lci5jcHA6MTk5KSAhdGltZXJIZWFwLT5pc0VtcHR5KCkKKworICAg ICAgICAqIHBsYXRmb3JtL1RpbWVyLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OlRpbWVyQmFzZTo6 c3RvcCk6IENhbGwgc2V0TmV4dEZpcmVUaW1lKDApIHVuY29uZGl0aW9uYWxseSB0byBtYWtlIHN1 cmUgdGhlIHRpbWVyCisgICAgICAgIGlzIHJlbW92ZWQgZnJvbSB0aW1lcnNSZWFkeVRvRmlyZSBz byB0aGF0IGZpcmVUaW1lcnMgZG9lc24ndCB0cnkgdG8gZmlyZSBhIGRlbGV0ZWQgdGltZXIuCisK IDIwMDYtMDItMTUgIERhdmUgSHlhdHQgPGh5YXR0QGFwcGxlLmNvbT4KIAogICAgICAgICBNYWtl IEZvbnRGYW1pbHkgY29tcGlsZSBvbiBXaW4zMiAoanVzdCBuZWVkZWQgYSBmZXcgbW9yZQpJbmRl eDogV2ViQ29yZS9wbGF0Zm9ybS9UaW1lci5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9wbGF0 Zm9ybS9UaW1lci5jcHAJKHJldmlzaW9uIDEyODE5KQorKysgV2ViQ29yZS9wbGF0Zm9ybS9UaW1l ci5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTE3Niw4ICsxNzYsNyBAQCB2b2lkIFRpbWVyQmFzZTo6 c3RhcnQoZG91YmxlIG5leHRGaXJlSW50CiB2b2lkIFRpbWVyQmFzZTo6c3RvcCgpCiB7CiAgICAg bV9yZXBlYXRJbnRlcnZhbCA9IDA7Ci0gICAgaWYgKG1fbmV4dEZpcmVUaW1lKQotICAgICAgICBz ZXROZXh0RmlyZVRpbWUoMCk7CisgICAgc2V0TmV4dEZpcmVUaW1lKDApOwogCiAgICAgQVNTRVJU KG1fbmV4dEZpcmVUaW1lID09IDApOwogICAgIEFTU0VSVChtX3JlcGVhdEludGVydmFsID09IDAp Owo=