Reload a DLL and _getptd returns zero

Michael Ost most at
Tue Jan 15 15:36:11 CST 2013

On 01/15/2013 01:08 PM, Piotr Caban wrote:
> On 1/15/13 7:59 PM, Michael Ost wrote:
>> On 01/15/2013 03:39 AM, Piotr Caban wrote:
>>> The crash is caused by incomplete FlsFree implementation. There's a
>>> comment in it's code that says what needs to be added:
>>> /* FIXME: add equivalent of ThreadZeroTlsCell here */
>> Really? Are you sure that's it?
> Yes. If you need a workaround to run you app you can comment FlsAlloc
> export. If this function is not available msvcrt will use TlsAlloc. I've

I can confirm that commenting out FlsAlloc does fix this crash. Wow!

Do you know what the implications are of using this hack? Would it 
simply be that any windows code that wants to use FlsAlloc would fail to 
load with a wine linkage error?

Also, is this what the VC runtimes that are statically compiled into a 
windows DLL do if FlsAlloc is unavailable? For backwards compatibility, 
I presume...?

> also confirmed it by adding a hacky implementation of zeroing the memory
> on free.

Is the "hacky implementation" the line:

"if (NtCurrentTeb()->FlsSlots) NtCurrentTeb()->FlsSlots[index] = 0;"

that I see in FlsFree? Because, if so, that doesn't fix the crash. If 
not, I'd be interested in seeing your hack because we might just use it.

>> By the way, to aid my future Wine sleuthing, can you share any hints
>> on how you figured this out?
> There's no easy answer to this question. I've looked on the relay log
> and after figuring out it may be related to Fls* functions I have added
> some more traces to it. Afterwards it was quite obvious that application
> was using a value that was supposed to be no longer valid (FlsGetValue
> was returning old pointer instead of NULL).

Thanks for this work!

-- mo

More information about the wine-devel mailing list