[Webkit-unassigned] [Bug 41105] fast/workers/storage/execute-sql-args-worker.html crashed on Leopard Commit Bot

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=41105





--- Comment #7 from Dumitru Daniliuc <dumi at chromium.org>  2010-06-23 17:43:29 PST ---
I think I found a scenario that would lead to this crash.

Short version: race condition that can happen only when using workers.

Long version:
In order to open a database, Database::openDatabase() calls (among other things) DatabaseTracker::canEstablishDatabase() and then DatabaseTracker::addOpenDatabase(). canEstablishDatabase() makes sure that the OriginQuotaManager instance used by DatabaseTracker starts tracking the given origin, but does not tell the DatabaseTracker that there's a new open database. addOpenDatabase() does the opposite: it tells DatabaseTracker() that a new database was opened, but it doesn't make sure that OriginQuotaManager is tracking this origin.

On the other hand, when a database is closed, it calls DatabaseTracker::removeOpenDatabase(), which tells DatabaseTracker to stop keeping track of this DB. Also, if this happens to be the last DB in this context that DatabaseTracker knows about, then it tells OriginQuotaManager to stop tracking this security origin too.

Now in the non-worker case, this is fine, because all these calls happen on the same context thread, so there's no race. When we have multiple workers though, the context threads are different for each worker, but they still share the same DatabaseTracker instance. So here's what I think happens:

1. Worker #1 runs DB test N.
2. OriginQuotaManager starts tracking this origin.
3. Worker #1 wants to shut down. This posts a task to the DatabaseThread of Worker #1, which will make sure all DBs are closed, all references are released, etc.
4. Meanwhile, Worker #2 starts running test (N+1), in the same security origin.
5. Worker #2 calls DatabaseTracker::canEstablishDatabase(). Nothing interesting happens, because OriginQuotaManager is still tracking this origin.
6. Worker #1 finally closes the DB used by test N, and calls DatabaseTracker::removeOpenDatabase(). At this point, DatabaseTracker doesn't know yet about the DB that will be opened in test (N+1), so as far as it's concerned, the last DB in this origin is being closed. Therefore, DatabaseTracker tells OriginQuotaManager to stop tracking this origin.
7. Worker #2 calls DatabaseTracker::addOpenDatabase(). DatabaseTracker is happy to start keeping track of this new DB, but doesn't tell OriginQuotaManager to re-start keeping track of this origin.
8. Now worker #2 gets to a transaction. Before the transaction can run, we need to know how much space is available to this origin. Since OriginQuotaManager is not tracking this origin, a NULL OriginUsageRecord is returned.


Solution: I think the best solution would be to call OriginQuotaManager::trackOrigin() whenever we call DatabaseTracker::addOpenDatabase().


I'm not sure if this is the problem that led to this crash, but it looks to me like it would lead to the same stack track, and I think it's worth fixing anyway.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.