[Webkit-unassigned] [Bug 32689] New: Fix the leak of ThreadIdentifiers in threadMap across threads.

[bugzilla-daemon at webkit.org]

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

           Summary: Fix the leak of ThreadIdentifiers in threadMap across
                    threads.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Template Framework
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: dimich at chromium.org
            Blocks: 31639


Working on adding asserts to RefCounted, I've added more calls to
WTF::currentThread() around. This made a problem we had before more pronounced
and caused crashes.

Currently, thread identifiers in Pthread-based ports are stored in a threadMap
which maps them to OS-provided thread handles. WTF::currentThread()
automatically generates a new ThreadIdentifier if the current thread does not
yet have a map entry. Unfortunately, some OSes (OSX at least, see test in the
discussion for bug 25348) reuse thread handles as soon as previous thread
terminates. If the thread does not call WTF::detachThread() which removes the
map entry, the new thread will have the same ThreadIdentifier which makes
comparing them bug-prone. This also causes existing assertion when a new thread
is created by WTF::createThread and finds out there is already ThreadIdentifier
from the previously existing non-WTF thread.

In addition, current WTF::detachThread(ThreadIdentifier) is often called from
another thread, which can happen after a thread with given ThreadIdentifier
already finished and a new one created, with the same OS handle. If the
ThreadIdentifier leaks in threadMap, it may cause detachThread to 'detach' the
new thread instead of old one.

Proposed modification is to add a thread-specific memory slot to store
ThreadIdentifier and remove the ThreadIdentifier from the threadMap in its
thread-specific destructor call. Since other thread-specific destructors can
invoke 'currentThread()' and re-establish the identifier, trigger the second
pass of the destructor which happens after all regular destructors already were
called. This way, the threads won't leave their ThreadIdentifiers in the map.

Other ports info: Windows threading does not have this issue because it uses
unique ThreadIdentifiers supplied by OS. Chromium uses Pthreads or Windows
threading so it's covered. So it leaves GTK and Qt ports which also use
threadMap, but I don't know GTK not Qt API well enough to provide a fix, and
hope the folks who maintain them will be able to see what, if anything, should
be done there. For example, if the respected OSes do not reuse thread handles
then there is no problem.

This patch will enable another attempt to fix bug 31639.

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