The buildbots are seeing this intermittently, but I can reproduce it nearly 100% of the time by doing the following: ./WebKitTools/Scripts/run-webkit-tests -g plugins storage Crash is as follows: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x5d781fc0 [Switching to process 62794 thread 0x6a27] 0x9097e4ed in pthread_mutex_unlock () (gdb) bt #0 0x9097e4ed in pthread_mutex_unlock () #1 0x020aeff0 in WebCore::Mutex::unlock (this=0x5d781fc0) at WebCore/platform/pthreads/ThreadingPthreads.cpp:168 #2 0x01d7370b in WebCore::MutexLocker::~MutexLocker (this=0xb032ccc0) at Threading.h:95 #3 0x01d73729 in WebCore::MutexLocker::~MutexLocker (this=0xb032ccc0) at Threading.h:95 #4 0x01faf51c in WebCore::SQLTransaction::cleanupAfterTransactionErrorCallback (this=0x5d781f60) at WebCore/storage/SQLTransaction.cpp:404 #5 0x01faf5f0 in WebCore::SQLTransaction::handleTransactionError (this=0x5d781f60, inCallback=false) at WebCore/storage/SQLTransaction.cpp:362 #6 0x01fafacc in WebCore::SQLTransaction::handleCurrentStatementError (this=0x5d781f60) at WebCore/storage/SQLTransaction.cpp:265 #7 0x01fafc2b in WebCore::SQLTransaction::runCurrentStatement (this=0x5d781f60) at WebCore/storage/SQLTransaction.cpp:249 #8 0x01fafd12 in WebCore::SQLTransaction::runStatements (this=0x5d781f60) at WebCore/storage/SQLTransaction.cpp:184 #9 0x01faebcb in WebCore::SQLTransaction::performNextStep (this=0x5d781f60) at WebCore/storage/SQLTransaction.cpp:97 #10 0x01c0f47a in WebCore::Database::performTransactionStep (this=0x5d1bfeb0) at WebCore/storage/Database.cpp:416 #11 0x01c14d95 in WebCore::DatabaseTransactionTask::doPerformTask (this=0x600f7fb0, db=0x5d1bfeb0) at WebCore/storage/DatabaseTask.cpp:112 #12 0x01c14cbb in WebCore::DatabaseTask::performTask (this=0x600f7fb0, db=0x5d1bfeb0) at WebCore/storage/DatabaseTask.cpp:58 #13 0x01c16564 in WebCore::DatabaseThread::dispatchNextTaskIdentifier (this=0x5d217f00) at WebCore/storage/DatabaseThread.cpp:182 #14 0x01c16627 in WebCore::DatabaseThread::databaseThread (this=0x5d217f00) at WebCore/storage/DatabaseThread.cpp:131 #15 0x01c16735 in WebCore::DatabaseThread::databaseThreadStart (vDatabaseThread=0x5d217f00) at WebCore/storage/DatabaseThread.cpp:115 #16 0x909a7075 in _pthread_start () #17 0x909a6f32 in thread_start () (gdb)
If I set MallocScribble=YES rather than using guard malloc, I see the following in the stderr output after the crash: ASSERTION FAILED: false (WebCore/platform/pthreads/ThreadingPthreads.cpp:169 void WebCore::Mutex::unlock()) Segmentation fault ASSERTION FAILED: false (WebCore/platform/pthreads/ThreadingPthreads.cpp:150 void WebCore::Mutex::lock()) Segmentation fault
<rdar://problem/5651076>
I suspect the underlying bug here was present prior to r28781, but the change to return as soon as an exception is raised somehow exposes the problem.
Created attachment 17964 [details] patch
Comment on attachment 17964 [details] patch r=me.
Committed revision 28811.