Bug 16468 – REGRESSION(r28781): Crash running storage/transaction_callback_exception_crash.html

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Mark Rowe (bdash)]

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)

[Mark Rowe (bdash)]

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

[Mark Rowe (bdash)]

<rdar://problem/5651076>

[Mark Rowe (bdash)]

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.

[Darin Adler]

Created attachment 17964 [details]
patch

[Mark Rowe (bdash)]

Comment on attachment 17964 [details]
patch

r=me.

[Darin Adler]

Committed revision 28811.