[Win] Crash under WorkQueue::performWorkOnRegisteredWorkThread in layout tests.
authorpvollan@apple.com <pvollan@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 31 Aug 2017 18:15:48 +0000 (18:15 +0000)
committerpvollan@apple.com <pvollan@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 31 Aug 2017 18:15:48 +0000 (18:15 +0000)
commitf421061f34b6ba98803ca663ff6ee18983e6d0f6
tree339062e450b86eebbf03dc3cf0860408992cfb07
parent1c4c7d69a78395536a588d7c813ffa559695f1df
[Win] Crash under WorkQueue::performWorkOnRegisteredWorkThread in layout tests.
https://bugs.webkit.org/show_bug.cgi?id=176163

Reviewed by Alex Christensen.

My previous attempt at fixing this crash in <http://trac.webkit.org/changeset/221323>
was incorrect, since it is still crashing on the bot(s). The current theory of why this
is failing is that the WorkQueue object deletes itself in the middle of the
performWorkOnRegisteredWorkThread method when calling deref(). There is no need to
increase the reference count of the work queue for each function we want to call on the
work thread. It is sufficient to increase it for every work thread we start, and then
dereference it when the thread ends. We should also not attempt to access members after
the deref() call, which can potentially be unsafe.

* wtf/win/WorkQueueWin.cpp:
(WTF::WorkQueue::workThreadCallback):
(WTF::WorkQueue::performWorkOnRegisteredWorkThread):
(WTF::WorkQueue::dispatch):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@221425 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WTF/ChangeLog
Source/WTF/wtf/win/WorkQueueWin.cpp