Plugin release build corrupts heap

Hi everyone !

My JUCE-plugins seem to have their GUI not working anymore in release. At startup, my debugger catches messages from the CRT about some evil things happening (typically reading or writing at NULL, unhandled exceptions, heap corruption, etc.) The “fun” thing is, it only happens in release config. Debug config is working absolutely fine…

The problem seems to have appeared when I upgraded to GIT tip (couple of days ago. I was using version from mid februrary 2011 previously, and it was working fine… I can probably trace back exact JUCE version if that is relevant.)

Some information that may be relevant :

  • I said the Problem is GUI-related, because when I load my plugin but leaves its GUI closed, it works fine. It’ll only crash when I open its GUI. Plus, in my company, it seems that most of the things using JUCE-GUI are broken now, as other things using JUCE non-GUI stuff are still working…
  • My plugins are using /MD (Multi-threaded DLL) version of CRT (since juce’s default seems to be /MT, this may play a role)
  • Using Visual Studio 2008. The plugin I describe below is Win32 VST, but it’s not the only place where I get issues, it’s just (hopefully) the easiest to debug…

Here is my (pseudo-)code :

	_heapchk(); // <- this one says the heap is valid at this point !

	// We are within some of my component's constructor, btw
	m_pMyComponent = new CMyComponent(this));

class CMyComponent: public CMyComponentBase
public :
	CMyComponent(CSomeOtherComponent* const pParent)
	:	CMyComponentBase(),
protected :
	CSomeOtherComponent* const m_pParent;

class CMyComponentBase : public Compoent
public :
	:	Component(L"CMyComponentBase")
		_heapchk(); // <- this one is already complaining that the heap is NOT valid anymore !
		// Do some other stuff... but as my heap is corrupt, no
		// wonder something is going to go wrong at some point...

Now, trying to understand what was happening, I changed a bit the release-config compile options to have debug information (so maybe this is not relevant at all, cause I cannot actually be sure my plugin is doing the same as before… but as I cannot debug assembly code, this is better than nothing…) Anyway, what came out, is that when calling my operator “new”, it (obviously) allocates a memory space that corresponds to the size of my CMyComponent object, but it also fills it with 0xbaadf00d…Which is odd, imho :

  • First, because there is a pattern (a release allocator shouldn’t waste time and fill allocated space with any pattern…)
  • Second, if any pattern, why baadf00d ? -> In debug config, newly allocated space is filled with 0xcdcdcdcd…

So, anybody with an idea ?..
Thanks in advance for your help !

cheers !


In debug mode, most of the classes contain an extra leak detector field, so their sizes and layouts are different to the way they are in a release build. So if you manage to build some of your files with bits of debug turned on, and other bits without, the result will be chaos…

Hi again…
Okay, I’ve been struggling a bit with this code (sorry for being unresponsive btw…) and I’ve found what was wrong. As I am writing, the whole application is being rebuild to validate it totally works but I am pretty confident it will…
So, if anybody is having a similar issue, here’s what was happening to me :

As you know, a juce project (application or plugin or lib or…) has one single “JuceHeader.h” (possibly not called like that, though) that your source includes. This header includes another (unique to your project) file “AppConfig.h” (also possibly called differently) that define a whole lot of macros which define compile/link options of Juce.
My mistake was to actually have not one, but two distinct “AppConfig.h”. That easy - that dumb… (also it was actually quite tricky to spot in a large application, especially as in my case, all macros were defined the same in debug, but not in release. The effect was exactly what you predicted, Jules : chaos…)

Anyway, thanks for everything !
Now it works : time for a beer…

Cheers !