| Summary: | A bug in SQLiteTransaction can lead to a failed ASSERT | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Dumitru Daniliuc <dumi> | ||||||
| Component: | New Bugs | Assignee: | Dumitru Daniliuc <dumi> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | andersca, aroben, beidson, darin, dglazkov | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Attachments: |
|
||||||||
Created attachment 33997 [details]
patch
Comment on attachment 33997 [details]
patch
Seems fine. Is there any way to make a regression test for this? Under what circumstances will the BEGIN command fail?
r=me
Should we need another assert after BEGIN. This shouldn't be happening normally, right? It seems like we should be doing something more than just reporting !inProgress in these cases. Created attachment 34000 [details] test case (In reply to comment #2) > (From update of attachment 33997 [details]) > Seems fine. Is there any way to make a regression test for this? Under what > circumstances will the BEGIN command fail? > > r=me BEGIN seems to fail if the same DB thread tries to run 2 transactions in 2 different Database objects that point to the same DB file. I attached the example we used. I don't have a detailed explanation for what's going on yet -- we think there's a race condition here and I'm still debugging it (details + patch to come in a future bug). However, always setting m_db.m_transactionInProgress to true seems wrong and leads to crashes in Chromium's and Safari's debug builds (you might have to click the "Test" button a couple of times). So I thought it wouldn't hurt to submit a quick patch for this before we're done investigating the bigger issue. Landed as http://trac.webkit.org/changeset/46736. Please create a bug for tracking the origin of the issue. |
SQLiteTransaction::begin() sets m_db.m_transactionInProgress to true even if m_db.executeCommand("BEGIN;") fails. This can lead to an ASSERT failing incorrectly in SQLTransaction::openTransaction() (steps 1 + 2).