Race in thread shutdown in imm32?

[Rob Shearman]

2008/11/17 James McKenzie <jjmckenzie51 at earthlink.net>:
> Rob Shearman wrote:
>> 2008/11/14 Dan Kegel <dank at kegel.com>:
>>
>>> I'm seeing the following valgrind warning
>>> in three out of eight runs under heavy load:
>>>
>>> InvalidRead
>>>  IMM_FreeThreadData:233
>>>  DllMain:382
>>>  __wine_spec_dll_entry:40
>>>  MODULE_InitDLL:911
>>>  LdrShutdownThread:2174
>>>  call_thread_func:403
>>>  start_thread:444
>>>
>>> It kind of feels like a race between thread shutdown and process shutdown.
>>> Does that ring a bell with anyone?
>>>
>>
>> IMM_FreeThreadData can crash if TlsGetValue returns a NULL pointer. On
>> first glance, it doesn't appear possible as IMM_InitThreadData is
>> called for every thread and on process startup. However, as you
>> surmise, it is possible in Wine for a thread to exit after the main
>> process has shut down (i.e. TlsFree(tlsIndex) has been called) and the
>> TLS area has been cleared, causing TlsGetValue to return 0.
>>
>> I believe that Windows terminates all threads on process exit, which
>> would solve this problem. However, the issue could trivially worked
>> around by introducing a NULL pointer check in IMM_FreeThreadData. It
>> would also be a good idea to set tlsIndex to TLS_OUT_OF_INDEXES after
>> TlsFree is called to avoid the possibility of using an un-allocated
>> TLS index.
>>
>>
> The question is how does Windows implement this feature?  Does it throw
> a 'kill' for all threads and then follows with a 'kill' for the entire
> process which may hang if one of the threads will not die?  If this is
> the method, we should duplicate it, but do a better job of handing the
> 'threads that will not die', IMHO.

There is no such thing as a thread "that will not die" on Windows.
Windows probably does the equivalent of TerminateThread for each
thread on ExitProcess being called, which terminates the thread with
no notifications and not cleaning anything up, including the stack
AFAIK, so it shouldn't ever fail.

> I'll look at the MSDN page that Ge van Geldorp pointed out to see if
> this is discussed.

-- 
Rob Shearman