Rob Shearman wrote:
2008/11/14 Dan Kegel dank@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.