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
Registers:
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
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.
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.
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.
