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? - Dan
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.
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.
2008/11/17 James McKenzie jjmckenzie51@earthlink.net:
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.
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.
-
Dan Kegel -
James McKenzie -
Rob Shearman