Ensure that scheduled tasks are executed during db thread shutdown

Source/core/workers/WorkerThread.cpp

 /*
  * Copyright (C) 2008 Apple Inc. All Rights Reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 210 matching lines @@
     // Mutex protection is necessary because stop() can be called before the context is fully created.
     MutexLocker lock(m_threadCreationMutex);
 
     // Signal the thread to notify that the thread's stopping.
     if (m_shutdownEvent)
         m_shutdownEvent->signal();
 
     // Ensure that tasks are being handled by thread event loop. If script execution weren't forbidden, a while(1) loop in JS could keep the thread alive forever.
     if (m_workerGlobalScope) {
         m_workerGlobalScope->script()->scheduleExecutionTermination();
-
-        DatabaseManager::manager().interruptAllDatabasesForContext(m_workerGlobalScope.get());

[adamk, 2014/02/27 17:28:26]

I've been curious for awhile about why this line wasn't inside
WorkerThreadShutdownStartTask; I assumed there was some reason it had to run
before stopDatabases(). I hope michaeln can shed some light on this.

Anyway, if it works, this change makes me very happy, as it gets us a good bit
closer to being able to remove the dependency from core -> modules/webdatabase.

[jochen (gone - plz use gerrit), 2014/02/27 19:40:55]

There might be SQLTransaction steps in the message loop. By interrupt the
database, they will all abort the transaction. However, the transaction needs to
be aborted on the DB thread as well, so the SQLTransactions all postTask to the
DB thread.

By interrupting here and then postTasking the databaseClose call, we can ensure
that all the abort transactions are scheduled before we invoke databaseClose.

The actual UaF is because all other code paths neither invoke interruptAllDBs
nor then postTask.

After my CL, some of the cleanup transactions might get scheduled on the
database thread after the database thread notifies the context thread that it
has terminated. However, we drain the entire message loop before joining the DB
thread, and the cleanup transactions themselves don't postTask anywhere nor use
V8.

         m_runLoop.postTaskAndTerminate(WorkerThreadShutdownStartTask::create());
         return;
     }
     m_runLoop.terminate();
 }
 
 bool WorkerThread::isCurrentThread() const
 {
     return m_threadID == currentThread();
 }
 
 class ReleaseFastMallocFreeMemoryTask : public ExecutionContextTask {
     virtual void performTask(ExecutionContext*) OVERRIDE { WTF::releaseFastMallocFreeMemory(); }
 };
 
 void WorkerThread::releaseFastMallocFreeMemoryInAllThreads()
 {
     MutexLocker lock(threadSetMutex());
     HashSet<WorkerThread*>& threads = workerThreads();
     HashSet<WorkerThread*>::iterator end = threads.end();
     for (HashSet<WorkerThread*>::iterator it = threads.begin(); it != end; ++it)
         (*it)->runLoop().postTask(adoptPtr(new ReleaseFastMallocFreeMemoryTask));
 }
 
 } // namespace WebCore