Crash related to ThreadLocalValue on WINXP 32 VST-Plugin

I could only reconstruct the Problem through Cubase.log and the compiler generated MAP-File, because i have no XP32 System here:

0002:00196600 ?get@?$ThreadLocalValue@PAVThread@juce@@@juce@@QBEAAPAVThread@2@XZ 103ff600 f i juce_core.obj
0002:00196560 ??1?$GenericScopedUnlock@VSpinLock@juce@@@juce@@QAE@XZ 103ff560 f i juce_core.obj
0002:001671e0 ?threadEntryPoint@Thread@juce@@AAEXXZ 103d01e0 f juce_core.obj
0002:001675d0 ?juce_threadEntryPoint@juce@@YAXPAX@Z 103d05d0 f juce_core.obj
0002:0018ab50 ?launchThread@Thread@juce@@AAEXXZ 103f3b50 f juce_core.obj
0002:0043d580 __beginthreadex 106a6580 f LIBCMTD:threadex.obj

Exception code: C0000005 ACCESS_VIOLATION
Fault address:  1041F618 02:00196618 C:\Programme\Steinberg\VstPlugins\MyPluginDebug.dll

EAX=00000000 ECX=00000000 EDX=10a3262c EBX=0fafa240 ESI=5b0f3935 EDI=  0012f6d4
EBP=0fa8fdf4 EIP=1041f618 ESP=0fa8fda4 CS= 0000001b SS= 00000023 Flags=00010202 
DS= 00000023 ES= 00000023 FS= 0000003b GS= 00000000

Float Save:
Control Word=  ffff027f Status Word=   ffff0000 Tag Word=ffffffff
Error Offset=  00000000 Error Selector=00120000
Data Offset=   00000000 Data Selector= ffff0000
Cr0NpxState=   00000000

Bytes at CS:EIP:
8b 04 81 05 04 01 00 00 5f 5e 5b 8b e5 5d c3 cc
cc cc cc cc cc cc cc cc 55 8b ec 83 ec 44 53 56

Call stack:
Address   Frame
1041F618  0FA8FDF4  0002:00196618 C:\Programme\Steinberg\VstPlugins\MyPluginDebug.dll
1041F5E4  0FA8FE4C  0002:001965E4 C:\Programme\Steinberg\VstPlugins\MyPluginDebug.dll
103F023A  0FA8FEC0  0002:0016723A C:\Programme\Steinberg\VstPlugins\MyPluginDebug.dll
103F05E1  0FA8FF14  0002:001675E1 C:\Programme\Steinberg\VstPlugins\MyPluginDebug.dll
10413BD9  0FA8FF6C  0002:0018ABD9 C:\Programme\Steinberg\VstPlugins\MyPluginDebug.dll
106C6843  0FA8FFA8  0002:0043D843 C:\Programme\Steinberg\VstPlugins\MyPluginDebug.dll
106C67B4  0FA8FFB4  0002:0043D7B4 C:\Programme\Steinberg\VstPlugins\MyPluginDebug.dll
7C80B729  0FA8FFEC  GetModuleFileNameA+1BA

The thread-locals are done with the standard __declspec(thread), which has been around for years and should be fine under XP.

Can’t think of a reason why it’d fail… If you want to tinker, you could try setting JUCE_NO_COMPILER_THREAD_LOCAL=1 to do it generically.

I just updated to the tip from 1.52, and I get the same or very similar crash. The generic version works fine. The backtrace looks like this, and the thread in question is the “Juce Timer” thread:

plugin.dll!juce::ThreadLocalValue<juce::Thread *>::get() Line 147 + 0xc bytes C++ plugin.dll!juce::ThreadLocalValue<juce::Thread *>::operator=(juce::Thread * const & newValue=0x0febc0f0) Line 99 + 0xf bytes C++ plugin.dll!juce::Thread::threadEntryPoint() Line 84 C++ plugin.dll!juce::juce_threadEntryPoint(void * userData=0x0febc0f0) Line 107 C++ plugin.dll!juce::threadEntryProc(void * userData=0x0febc0f0) Line 119 + 0x9 bytes C++ plugin.dll!_callthreadstartex() Line 348 + 0xf bytes C plugin.dll!_threadstartex(void * ptd=0x06f5cc88) Line 331 C

I’m running XP32, and compiling with VS2005, if that makes any difference. I had to install the Win 7 SDK and a hotfix for VS2005 before I could compile successfully.


Jules, now it works with JUCE_NO_COMPILER_THREAD_LOCAL=1
Scooped27 also uses XP32 and has the same bug, so i think its obvious that there is a problem at least with XP32.

I forgot to say, yes i also use the Timer!

Gahh… Seems that thread-locals are ok in XP if it’s an EXE, but not if it’s a dynamically-loaded DLL. I guess I’ll just turn it off for plugins and leave it on for apps.

This seems to be the problem we are encountering on our project. We set JUCE_NO_COMPILER_THREAD_LOCAL=1 to see if we can avoid the crash in XP, but it fails anyways. We need to use JUCE as a DLL because it is a requirement of ADOBE Flash. Does anyone know of a work-around for this problem? The code works on Vista and Windows 7, but crashes on XP.


Actually, it does appear to work to set JUCE_NO_COMPILER_THREAD_LOCAL=1 . Thanks.


What would be the impact of setting JUCE_NO_COMPILER_THREAD_LOCAL = 1 on a 64-bit, Windows 7 Machine. Would it just make things run a little slower or might there be something more ominous?

Very little impact - it just means it’ll use my thread-local class instead of compiler-native thread locals, which might have been a bit more efficient.

Is there any chance to make the interface to ThreadLocalValue work like boost?

Here’s the description:

At a brief glance I couldn’t see anything much in there that my class doesn’t do, apart from the clean-up function.

Well yeah that’s the whole thing right there: