SOLVED: Timer in JuceDemoPlugin crashes 64bitHost on WinXP64

Windows
#1

Hello guys,

I ran into a problem, when trying to get the JuceDemo Plugin running as a 64bit VST Plugin on WinXP 64bit. The host opens up but as soon as I load the plugin into a track the host just quits.

I am compiling with VisualStudio2010 on Win7 64bit. The plugin works fine on Win7, but when I try to open the 64bit version on WinXP it crashes the host.
It probably has to be something in the project settings in VS2010, so here´s what I already tested:
.NET Framework 3.5 & 4
WinSDK 7.1, v100 & v90
I also did a test with VS2008 on WinXP which caused the same problem.

Does anyone have a clue, what I am doing wrong?

Thank you!
Gabriel

#2

I thought maybe it´s helpful, if I post some more info:

First of all I noticed, the the Demo Plugin opens in the JuceDemo Plugin Host without causing any problems.
But if I open it in ViennaEnsemblePro x64 it just quits the host.
I used VS2008 as a Debugger and the point at which VEPro is quitting is:

“Type& get() const no except” in “juce_ThreadLocalValue.h” and the problem seems to be somewhere in juce::timer::TimerThread

I already deleted all the code that belongs to the Timer in the Juce Demo Plugin but that didn´t change anything.

Any thoughts ?

#3

I found out some more:
The call that finally causes the problem is started from

void handlesAsyncUpdate() { startThread (7); }
in juce_Timer.cpp

#4

You need to actually debug… It seems quite odd that the “cause” would be started from juce::Thread::startThread.

#5

Thanks for the answer!
I am pretty new to debugging, I am basically just setting various Breakpoints and see what happens when I comment some stuff out, but I got some new results:

After I commented out startTimer() in both juce_VST_Wrapper.cpp and juce_win32_Windowing.cpp the plugin started just fine, so now I know it´s a problem with the Timer and it seems to be somehow GUI related (in juce_VST_Wrapper startTimer() is called from the dispatcher with opCode == effEditOpen)

Nevertheless I still don´t have a clue, why this happens only on XP64bit and how to fix it.

#6

Just a basic stack trace of the crash would probably be the most helpful thing to start with here.

#7

Thanks for the advice Jules, this is the stack trace I get, after the host crashed

JuceDemoPlugin_x64.dll!juce::ThreadLocalValue<juce::Thread * __ptr64>::get() Zeile 150 + 0x16 Bytes
JuceDemoPlugin_x64.dll!juce::ThreadLocalValue<juce::Thread * __ptr64>::operator=(juce::Thread * const & newValue=0x000000000304d620) Zeile 101 + 0x18 Bytes
JuceDemoPlugin_x64.dll!juce::Thread::threadEntryPoint() Zeile 83
JuceDemoPlugin_x64.dll!juce::juce_threadEntryPoint(void * userData=0x000000000304d620) Zeile 106
JuceDemoPlugin_x64.dll!juce::threadEntryProc(void * userData=0x000000000304d620) Zeile 121
JuceDemoPlugin_x64.dll!_callthreadstartex() Zeile 348 + 0x17 Bytes
JuceDemoPlugin_x64.dll!_threadstartex(void * ptd=0x0000000003505260) Zeile 331
kernel32.dll!0000000077d6b6da()

As you maybe guessed “Zeile” is the german word for line :wink:

Let me know, if I should check the values of some variables at any of these spots.

#8

I think that thread local storage is not working in a DLL in WinXP.

There is a comment in Juce regarding this.

#9

Yeah, if you want it to work in that context, you’ll need to build with JUCE_NO_COMPILER_THREAD_LOCAL = 1.

#10

You guys are amazing! JUCE_NO_COMPILER_THREAD_LOCAL did the trick. Thank you very much!