Race in thread shutdown in imm32?

James McKenzie jjmckenzie51 at earthlink.net
Sun Nov 16 18:32:05 CST 2008

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.

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

More information about the wine-devel mailing list