PLT dies in timer code

[Eric Seidel (no email)]

I discovered this evening the bug which I believe has been the cause of the PLT failures for the last several days.  (Chris has not been able to get results since 2/10).

I ran this command:

run-plt --leave-prefs "activate; run cvs-base; emptyCache; clearHistory; wait 30; run cvs-base; wait 10; run cvs-base; wait 10; run cvs-base; wait 10; run cvs-base; wait 10; run cvs-base; wait 10; run cvs-base"   

and caught Safari dying in the debugger:

Program received signal SIGABRT, Aborted.
0x9004714c in kill ()
(gdb) bt
#0  0x9004714c in kill ()
#1  0x90128b98 in abort ()
#2  0x946f3eb4 in __gnu_cxx::__verbose_terminate_handler ()
#3  0x946f1a54 in __cxxabiv1::__terminate ()
#4  0x946f1ab8 in std::terminate ()
#5  0x946f2164 in __cxa_pure_virtual ()
#6  0x01e6b7e4 in WebCore::TimerBase::fireTimers (fireTime=1140060708.2481711, firingTimers=@0xbfffe238) at /Build/Safari-TOT/OpenSource/WebCore/platform/Timer.cpp:333
#7  0x01e6b890 in WebCore::TimerBase::sharedTimerFired () at /Build/Safari-TOT/OpenSource/WebCore/platform/Timer.cpp:350
#8  0x90770aec in __CFRunLoopDoTimer ()
#9  0x9075d464 in __CFRunLoopRun ()
#10 0x9075ca18 in CFRunLoopRunSpecific ()
#11 0x9318f1e0 in RunCurrentEventLoopInMode ()
#12 0x9318e874 in ReceiveNextEventCommon ()
#13 0x9318e6e0 in BlockUntilNextEventMatchingListInMode ()
#14 0x9368d104 in _DPSNextEvent ()
#15 0x9368cdc8 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#16 0x0001c324 in -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (self=0xf11d690, _cmd=0x0, mask=4294967295, expiration=0xf1720e0, mode=0x2d, dequeue=1 '\001') at /Build/Safari-TOT/Internal/WebBrowser/BrowserApplication.m:152
#17 0x9368930c in -[NSApplication run] ()
#18 0x93779e68 in NSApplicationMain ()
#19 0x00003114 in _start (argc=3, argv=0xbffff5b0, envp=0xbffff5c0) at /SourceCache/Csu/Csu-58/crt.c:272
#20 0x00002fbc in start ()

This bug seems to only reproduce with TOT Safari (and thus has not been affecting the PLT slave... I don't think.)

[Alexey Proskuryakov]

Might have been fixed in bug 7274.

[Geoffrey Garen]

A call to a pure virtual method wouldn't compile, so I suspect it's the result of a corrupted vtable, in turn the result of a prematurely deallocated object. MallocScribble or, if you have a few years, libgmalloc, may help track this down.

[Geoffrey Garen]

Seems like this might be a dup of bug 7274.

[Darin Adler]

Eric, is this still happening after the fix for bug 7274 or not?

[Eric Seidel (no email)]

This is gone now.  Closing.

*** This bug has been marked as a duplicate of 7274 ***