16468 2007-12-17 00:54:12 -0800 REGRESSION(r28781): Crash running storage/transaction_callback_exception_crash.html 2007-12-17 09:53:47 -0800 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Mac OS X 10.4 RESOLVED FIXED InRadar, Regression P1 Normal --- 1 mrowe darin darin mrowe oldest_to_newest 64484 0 mrowe 2007-12-17 00:54:12 -0800 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) 64485 1 mrowe 2007-12-17 01:02:24 -0800 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 64531 2 mrowe 2007-12-17 08:13:19 -0800 <rdar://problem/5651076> 64532 3 mrowe 2007-12-17 08:14:21 -0800 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. 64540 4 17964 darin 2007-12-17 09:41:04 -0800 Created attachment 17964 patch 64541 5 17964 mrowe 2007-12-17 09:51:30 -0800 Comment on attachment 17964 patch r=me. 64542 6 darin 2007-12-17 09:53:47 -0800 Committed revision 28811. 17964 2007-12-17 09:41:04 -0800 2007-12-17 09:51:30 -0800 patch DatabaseRefPtrPatch.txt text/plain 1449 darin SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiAyODgxMCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTQgQEAKKzIwMDctMTItMTcgIERhcmluIEFkbGVyICA8ZGFyaW5AYXBwbGUuY29t PgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIC0gZml4 IGh0dHA6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE2NDY4CisgICAgICAgICAg UkVHUkVTU0lPTihyMjg3ODEpOiBDcmFzaCBydW5uaW5nIHN0b3JhZ2UvdHJhbnNhY3Rpb25fY2Fs bGJhY2tfZXhjZXB0aW9uX2NyYXNoLmh0bWwKKworICAgICAgICAqIHN0b3JhZ2UvRGF0YWJhc2VU aHJlYWQuY3BwOgorICAgICAgICAoV2ViQ29yZTo6RGF0YWJhc2VUaHJlYWQ6OmRpc3BhdGNoTmV4 dFRhc2tJZGVudGlmaWVyKTogVXNlIGEgUmVmUHRyIGZvciB0aGUgZGF0YWJhc2UKKyAgICAgICAg YmVjYXVzZSB0aGVyZSdzIG5vIGd1YXJhbnRlZSBpdCB3b24ndCBsb3NlIGl0cyBsYXN0IHJlZmVy ZW5jZSBvdGhlcndpc2UuCisKIDIwMDctMTItMTcgIERhbiBCZXJuc3RlaW4gIDxtaXR6QGFwcGxl LmNvbT4KIAogICAgICAgICBSZXZpZXdlZCBieSBNYWNpZWogU3RhY2hvd2lhay4KSW5kZXg6IFdl YkNvcmUvc3RvcmFnZS9EYXRhYmFzZVRocmVhZC5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9z dG9yYWdlL0RhdGFiYXNlVGhyZWFkLmNwcAkocmV2aXNpb24gMjg3OTEpCisrKyBXZWJDb3JlL3N0 b3JhZ2UvRGF0YWJhc2VUaHJlYWQuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0xNTUsNyArMTU1LDcg QEAgdm9pZCogRGF0YWJhc2VUaHJlYWQ6OmRhdGFiYXNlVGhyZWFkKCkKIAogYm9vbCBEYXRhYmFz ZVRocmVhZDo6ZGlzcGF0Y2hOZXh0VGFza0lkZW50aWZpZXIoKQogewotICAgIERhdGFiYXNlKiB3 b3JrRGF0YWJhc2UgPSAwOworICAgIFJlZlB0cjxEYXRhYmFzZT4gd29ya0RhdGFiYXNlOwogICAg IFJlZlB0cjxEYXRhYmFzZVRhc2s+IHRhc2s7CiAKICAgICB7CkBAIC0xNzksNyArMTc5LDcgQEAg Ym9vbCBEYXRhYmFzZVRocmVhZDo6ZGlzcGF0Y2hOZXh0VGFza0lkZQogICAgIGlmICh0YXNrKSB7 CiAgICAgICAgIEFTU0VSVCh3b3JrRGF0YWJhc2UpOwogICAgICAgICB3b3JrRGF0YWJhc2UtPnJl c2V0QXV0aG9yaXplcigpOwotICAgICAgICB0YXNrLT5wZXJmb3JtVGFzayh3b3JrRGF0YWJhc2Up OworICAgICAgICB0YXNrLT5wZXJmb3JtVGFzayh3b3JrRGF0YWJhc2UuZ2V0KCkpOwogICAgICAg ICByZXR1cm4gdHJ1ZTsKICAgICB9CiAK