Juce Demo and plugin host crash at startup ?!


#1

Hi Jules !

I think I hit a bug since a few versions of juce (I managed to reproduce it with the very latest tip) . It affects several Juce executables (the demo, the plugin host), without any change in the code. Just opening the solution and building, right after download, triggers the following :

The assertion “jassert (isPositiveAndBelow (index, numUsed));” fails. index is 2 and numUsed is 43674108 (!)
Here is the stack trace :

JuceDemo.exe!juce::Array<juce::String,juce::DummyCriticalSection>::getReference(const int index=2) Ligne 256 + 0x6c octets C++ JuceDemo.exe!juce::StringArray::joinIntoString(const juce::String & separator={data=0x029a6acc " " }, int start=1, int numberToJoin=-1) Ligne 323 + 0xc octets C++ JuceDemo.exe!juce::PlatformUtilities::getCurrentCommandLineParams() Ligne 202 + 0x25 octets C++ JuceDemo.exe!WinMain(int __formal=1245184, int __formal=1245184, int __formal=1245184, int __formal=1245184) Ligne 155 + 0x3b octets C++ JuceDemo.exe!__tmainCRTStartup() Ligne 263 + 0x2c octets C JuceDemo.exe!WinMainCRTStartup() Ligne 182 C

If I bypass the assert, the program crashes in

size_t sizeInBytes() const throw() { return strlen (data) + 1; }

The interesting bit is that data points to 0xcdcdcdcd which is a special value filled by visual c++ debug runtime to indicate some memory which has been allocated but not initialized.

HTH


#2

Are you sure you’ve not just got some kind of corrupted link going on? I’ve been happily running it on win32 with no problems, and there’s nothing I can see that’s wrong with that method, it runs perfectly for me… ?

Unless there’s some kind of difference between our environments… Which version of windows and MSVC are you using?


#3

I’m under windows 7 64 bit (but making a 32 bit build), with visual studio 2008 .
After further investigation, I noticed that it happens if and only if I #define JUCE_CHECK_MEMORY_LEAKS 0 in juce_Config.h !
(So I was wrong, I actually changed one thing) . This change alone is enough to reproduce the bug. It’s as if your memory leak checker had a side effet which prevented a bug


#4

Hmm, I guess the difference is that I’m only running 32-bit windows. Thanks, I’ll investigate…


#5

Has anything turned up with this yet? In code based on the example host, with the memory leak checking turned off, I’m also firing an assert at jassert (isPositiveAndBelow (index, numUsed)). The debugger at this point shows index to be 5 and numUsed to be 7.

This is on Mac 10.6.4 building a 32 bit target on a 64 bit machine.

#0	0x904162e6 in Debugger
#1	0x00e451a1 in juce::OwnedArray<juce::AudioProcessorGraph::Connection, juce::DummyCriticalSection>::getUnchecked at juce_OwnedArray.h:124
#2	0x00e42003 in juce::AudioProcessorGraph::isAnInputTo at juce_AudioProcessorGraph.cpp:976
#3	0x00e42fbc in juce::AudioProcessorGraph::buildRenderingSequence at juce_AudioProcessorGraph.cpp:1008
#4	0x00e4338b in juce::AudioProcessorGraph::handleAsyncUpdate at juce_AudioProcessorGraph.cpp:1046
#5	0x00e5df46 in juce::AsyncUpdaterMessage::messageCallback at juce_AsyncUpdater.cpp:47
#6	0x00e6090c in juce::MessageManager::deliverMessage at juce_MessageManager.cpp:114
#7	0x01028917 in juce::MessageQueue::deliverNextMessage at juce_mac_NativeCode.mm:167
#8	0x010289a6 in juce::MessageQueue::runLoopCallback at juce_mac_NativeCode.mm:174
#9	0x010289eb in juce::MessageQueue::runLoopSourceCallback at juce_mac_NativeCode.mm:183
#10	0x98a590fb in __CFRunLoopDoSources0
#11	0x98a56bbf in __CFRunLoopRun
#12	0x98a56094 in CFRunLoopRunSpecific
#13	0x98a55ec1 in CFRunLoopRunInMode
#14	0x92ad7f9c in RunCurrentEventLoopInMode
#15	0x92ad7c8d in ReceiveNextEventCommon
#16	0x92c601e3 in ReceiveNextEvent

#6

Same assert, but in a different place … Has anyone experience the problem on a 32bit machine ?


#7

It all works perfectly for me - are you sure it’s not being caused by a plugin going wrong?


#8

Is the Juce Demo using plugins in any way ? To reproduce I just download Juce, change the flag for catching leaks in juce_Config.h, recompile and the demo crashes. No other change. Same behaviour for any Juce-based program I tried.

The thing I have in comon with XiGO is I’m also under 64 bit (but windows) building a 32 bit target.

It might be something trivial though. I didn’t really investigate it. I will try to when I have time.


#9

Someone else in the thread was talking about the plugin host app.

The problem is that you must have changed the config flag for some of your cpp files, but not for all of them, so different modules are getting compiled using different versions of the juce classes, with memory layouts that don’t quite match. So when they’re linked together, it’ll all be extremely broken!


#10

That’s weird, even from a clean rebuild of everything (so, using the same juce_Config.h) I still have the problem. Also that’s the only weird behaviour I have in the whole application. It’s not extremely annoying though but it’s strange…
If you disable the leak checker in juce_Config.h, you don’t have any issue under windows ?