Reload a DLL and _getptd returns zero

Michael Ost most at
Sun Jan 13 15:59:13 CST 2013

On 1/13/13 1:17 PM, Marcus Meissner wrote:
> 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:
>> 1. [main] start a thread
>> 2. [main] load a library
>> 3. [thread] call std::cout<< from the library
>> 4. [main] free the library
>> 5. [main] reload the library
>> 6. [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?

It's statically linked in Windows.

> And why free/reload a statically linked library?

We load and unload the DLL that has MSCVRT statically linked into it. 
Our program is a "plugin player", that loads (and unloads) VST sound 
plugins for musicians to perform with.

-- mo

More information about the wine-devel mailing list