On Fri, Jan 11, 2013 at 11:24:55AM -0800, Michael Ost wrote:
Hi list,
Does anyone know why _getptd() calls would return zero on a DLL that has been reloaded? Does something happen to the TLS used by _getptd?
At Muse Research we have been struggling with a deep bug for years where there is a crash _sometimes_ if you load a DLL a second time.
Finally (with a big tip of the hat to Julien Pommier at PianoTeq!) we have a test case that demonstrates a (if not _the_) crash.
The sequence is:
- [main] start a thread
- [main] load a library
- [thread] call std::cout<< from the library
- [main] free the library
- [main] reload the library
- [thread] call std::cout<< from the library
-> crash!
It looks like the crash happens because the MSVCRT function _getptd() is returning zero in step 6. This is dereferenced and crashes. In windows, there is no crash.
The library in question is using static vc runtime linkage, so _getptd() is linked in and I don't know exactly what it is doing. But Wine's MSVCRT implementation of _getptd() gets its data from TlsGetValue. And I can see that just before the crash there is a TlsGetValue call that returns zero.
Looking at TlsGetValue(), there must be something wrong with the values in TlsSlots. Maybe they persist for DLLs in Windows in a way they don't for Wine...? Or maybe Wine doesn't reinitialize them the same way when the DLL is reloaded?
Any hints, thoughts? clues? Thanks!
Is this statically linked msvcrt from Wine or Windows?
And why free/reload a statically linked library?
Ciao, Marcus