Heap corruption in demo plugin host after loading demo plugi

Windows
1

Latest tip, JUCE Demo Plugin Host project + JUCE Demo Plugin project, Windows 7, 32-bit VS2010 debug build.

I have a VST folder with a range of free and commercial plugins which the Juce demo host can scan fine. However, when I add a ‘vanilla’ Juce demo plugin dll to the folder, the demo host suffers from heap corruption sometime during or after scanning it (an example below, but the place in which it occurs is not repeatable). Other DAWs eg. (Reaper) can scan both my third party plugins and the Juce demo plugin without problem.

If the Juce demo dll is the only VST in the folder, then there’s often a chance that’ll load fine (although this is not guaranteed). If other VSTs are loaded after it during the scan process, then there’s a higher likelihood of heap corruption occurring (suggesting the damage has already been done, it’s just time before it shows up).

An example (although the exact place that the corruption is detected varies between runs):

Thread which reported the heap corruption:

ntdll.dll!774504e4() 	
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
ntdll.dll!7740b023() 	
ntdll.dll!7740a71a() 	
ntdll.dll!773d7cb1() 	
kernel32.dll!75dc9976() 	
kernel32.dll!75dc9acf() 	
kernel32.dll!75dc9aee()

Plugin Host.exe!juce::File::moveInternal(const juce::File & dest={…}) Line 205 + 0x1f bytes C++
Plugin Host.exe!juce::File::moveFileTo(const juce::File & newFile={…}) Line 250 C++
Plugin Host.exe!juce::TemporaryFile::overwriteTargetFileWithTemporary() Line 84 + 0xf bytes C++
Plugin Host.exe!juce::File::replaceWithText(const juce::String & textToWrite={…}, const bool asUnicode=true, const bool writeUnicodeHeaderBytes=true) Line 714 + 0x8 bytes C++
Plugin Host.exe!juce::PluginDirectoryScanner::setDeadMansPedalFile(const juce::StringArray & newContents={…}) Line 114 + 0x48 bytes C++
Plugin Host.exe!juce::PluginDirectoryScanner::scanNextFile(const bool dontRescanIfAlreadyInList=true) Line 95 C++
Plugin Host.exe!juce::PluginListComponent::Scanner::timerCallback() Line 262 + 0x10 bytes C++
Plugin Host.exe!juce::timer::TimerThread::callTimers() Line 128 C++
Plugin Host.exe!juce::timer::TimerThread::CallTimersMessage::messageCallback() Line 197 C++
Plugin Host.exe!juce::WindowsMessageHelpers::dispatchMessageFromLParam(long lParam=52830256) Line 50 C++
Plugin Host.exe!juce::MessageManager::dispatchNextMessageOnSystemQueue(const bool returnIfNoPendingMessages=false) Line 111 + 0x9 bytes C++
Plugin Host.exe!juce::MessageManager::runDispatchLoopUntil(int millisecondsToRunFor=-1) Line 119 + 0x10 bytes C++
Plugin Host.exe!juce::MessageManager::runDispatchLoop() Line 100 C++
Plugin Host.exe!juce::JUCEApplication::main() Line 246 C++
Plugin Host.exe!WinMain(void * __formal=0x002c0000, void * __formal=0x002c0000, void * __formal=0x002c0000, void * __formal=0x002c0000) Line 107 + 0x18 bytes C++
Plugin Host.exe!__tmainCRTStartup() Line 275 + 0x2c bytes C
Plugin Host.exe!WinMainCRTStartup() Line 189 C
kernel32.dll!75db33aa()
ntdll.dll!773b9ef2()
ntdll.dll!773b9ec5()
Plugin Host.exe!juce::MemoryBlock::setBitRange(const unsigned int bitRangeStart=6619252, unsigned int numBits=6357064, int bitsToSet=6553710) Line 307 + 0x21 bytes C++

Debug output:

Creating VST instance: geektronic *** Unhandled VST Callback: 42 Initialising VST: geektronic The thread 'Win32 Thread' (0x1c44) has exited with code 1 (0x1). Attempting to load VST: C:\VST Plugins\HighLife_Debug.dll Creating VST instance: HighLife_Debug Initialising VST: HighLife_Debug Attempting to load VST: C:\VST Plugins\JuceDemoPlugin.dll JUCE v2.0.32 Creating VST instance: JuceDemoPlugin Initialising VST: JuceDemoPlugin HEAP[Plugin Host.exe]: HEAP: Free Heap block ccdb78 modified at ccdba0 after it was freed Windows has triggered a breakpoint in Plugin Host.exe.

This may be due to a corruption of the heap, which indicates a bug in Plugin Host.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while Plugin Host.exe has focus.

The output window may have more diagnostic information.

Creating VST instance: geektronic
*** Unhandled VST Callback: 42
Initialising VST: geektronic
The thread ‘Win32 Thread’ (0x13bc) has exited with code 1 (0x1).
Attempting to load VST: C:\VST Plugins Test\HighLife_Debug.dll
Creating VST instance: HighLife_Debug
Initialising VST: HighLife_Debug
Attempting to load VST: C:\VST Plugins Test\JuceDemoPlugin.dll
JUCE v2.0.32
Creating VST instance: JuceDemoPlugin
Initialising VST: JuceDemoPlugin
Attempting to load VST: C:\VST Plugins Test\MDA\mda Bandisto.dll
Creating VST instance: mda Bandisto
Initialising VST: mda Bandisto
HEAP[Plugin Host.exe]: HEAP: Free Heap block 3db830 modified at 3db858 after it was freed
Windows has triggered a breakpoint in Plugin Host.exe.

This may be due to a corruption of the heap, which indicates a bug in Plugin Host.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while Plugin Host.exe has focus.

The output window may have more diagnostic information.

2

OK, some further info - building the demo plugin in Release configuration results in it loading fine.

Is this a known problem/limitation? It’d be nice to have a debug build plugin running under the host.

3

If you load a juce plugin DLL into a juce host exe, then you can get situations where both modules export symbols with the same name, and they can get cross-wired, so the wrong functions get called and the wrong heap is used, etc. That’s probably what’s happening here. It goes away in a release build because no symbols are visible.

4

I was hoping to run a debug plugin under a release host, but changing the debug/release configuration of the host seems make no difference to the problem.

It seems that the problem’s down to the plugin using the debug runtime library, since I could to resolve it by changing the ‘Runtime Library’ for the plugin’s debug build from ‘Multi-threaded debug’ to just ‘Multi-threaded’. I also had to remove ‘_DEBUG’ from the Preprocessor Definitions to avoid missing symbols at link time (it was still looking for the debug versions). It’s been a little while since I worked with Windows so I’m not quite sure about the side effects of this.

Still, at least it means that it should be possible to debug the plugin with its debug symbols available, even if it’s using the release runtime.

5

You can generate debug information for release builds, if you compile the IntroJucer from the latest tip. See this post:

http://www.rawmaterialsoftware.com/viewtopic.php?f=7&t=9159

6

I’m running Debug builds with Release hosts since years, never had such problems.

Did you start the Debugging from the Plugin project and defined plugin host.exe as executeable, the way i do?

7

I was more interested in seeing how the host works, so I was running the host in the debugger. I haven’t yet tried debugging the plugin by invoking the host exe, but I did try ‘attach to process’ which worked fine.

If the plugin uses the debug runtime, the host will often crash regardless of any debug connection.