Reload a DLL and _getptd returns zero

[Michael Ost]

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