Has any seen runtime problems with JUCE in debug mode?

Windows
1

I’m encountering problems building my application with JUCE and thought someone could help. My application requires C++ standard library calls which means that I have to link against the DLL versions of the Microsoft C++ runtime libraries.

First I tried to build the JUCE library in debug mode and link it to my application which has been built in debug mode, when I run the application it halts immediately and I get the System message: “An application has made an attempt to load the C runtime library incorrectly, Please contact the application’s support team.”

If I then compile my application in debug mode and link to a version of JUCE that is built in release mode, I no longer see this problem. Unfortunately, I do see runtime errors that are undoubtedly related to this mixing of release and debug models. Usually it crashes on a JUCE call that’s performing some sort of malloc or free.

Has anybody seen any of this type of behavior before? I’m including a stack trace so you can better see what’s happening at runtime.

[code]Unhandled exception at 0x1021c2b2 (msvcr80d.dll) in TuneUpApp.exe: 0xC0000005: Access violation reading location 0xfeeefee8.

msvcr80d.dll!CheckBytes(unsigned char * pb=0xfeeefee8, unsigned char bCheck=‘í’, unsigned int nSize=3) Line 1654 + 0x7 bytes C++
msvcr80d.dll!_free_dbg_nolock(void * pUserData=0xfeeefeee, int nBlockUse=1) Line 1257 + 0x17 bytes C++
msvcr80d.dll!_free_dbg(void * pUserData=0xfeeefeee, int nBlockUse=1) Line 1220 + 0xd bytes C++
msvcr80d.dll!free(void * pUserData=0xfeeefeee) Line 1178 + 0xb bytes C++
TuneUpApp.exe!_png_free() + 0x20 bytes C
TuneUpApp.exe!_png_free_data() + 0x87 bytes C
TuneUpApp.exe!png_destroy_read_struct() + 0x4b bytes C
TuneUpApp.exe!juce::juce_loadPNGImageFromStream() + 0x16f bytes C++
TuneUpApp.exe!juce::PNGImageFormat::decodeImage() + 0xa bytes C++
TuneUpApp.exe!juce::ImageFileFormat::loadFrom() + 0x16 bytes C++
TuneUpApp.exe!juce::ImageFileFormat::loadFrom() + 0x52 bytes C++
TuneUpApp.exe!juce::ImageCache::getFromMemory() + 0x2c bytes C++
TuneUpApp.exe!CTuneUpIconBarChooser::GetImageFromFile(const int resID=123, juce::String fileName={…}) Line 278 + 0xd bytes C++
TuneUpApp.exe!CTuneUpIconBarChooser::buttonToItem(juce::Button * button=0x015281c8) Line 167 + 0x20 bytes C++
TuneUpApp.exe!CTuneUpIconBarChooser::buttonClicked(juce::Button * button=0x015281c8) Line 236 + 0xf bytes C++
TuneUpApp.exe!juce::Button::sendClickMessage() + 0x91 bytes C++
TuneUpApp.exe!juce::Button::internalClickCallback() + 0x3b bytes C++
TuneUpApp.exe!juce::Button::handleCommandMessage() + 0x33 bytes C++
TuneUpApp.exe!juce::MessageManager::deliverMessage() + 0x5d bytes C++
TuneUpApp.exe!juce::juce_dispatchNextMessageOnSystemQueue() + 0x65 bytes C++
TuneUpApp.exe!juce::MessageManager::dispatchNextMessage() + 0x46 bytes C++
TuneUpApp.exe!juce::MessageManager::runDispatchLoop() + 0x6 bytes C++
TuneUpApp.exe!juce::JUCEApplication::main() + 0x1e1 bytes C++
TuneUpApp.exe!WinMain(HINSTANCE * formal=0x00400000, HINSTANCE * formal=0x00400000, char * commandLine=0x00151f19, HINSTANCE * __formal=0x00400000) Line 20 + 0x7f bytes C++
TuneUpApp.exe!__tmainCRTStartup() Line 589 + 0x35 bytes C
TuneUpApp.exe!WinMainCRTStartup() Line 414 C
kernel32.dll!7c816fd7()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
[/code]

Any tips would be much appreciated.
=Gabe

2

I’m wondering if you should be building with the regular multi-threaded libraries instead. As far as I know, you should only use the DLL versions of the libraries if you are building a DLL; your stack trace looks like you’re building an application.

3

I’m wondering if you should be building with the regular multi-threaded libraries instead. As far as I know, you should only use the DLL versions of the libraries if you are building a DLL; your stack trace looks like you’re building an application.[/quote]

You’re correct, I am building an application. However, according to the MSDN docs, any application that uses the Standard C++ library will need msvcrt.lib (msvcr80.dll) to run. If you make any C++ standard library calls in your application at all, the DLL version of the runtime library is automatically linked in and you have to explicitly tell the linker to ignore the static version of the runtime library (libcmt.lib). I’d be very curious to find out if anyone has had a successful experience with linking a debug JUCE project against the DLL C runtime libraries??

4

Looking at the juce_application sample in VS 2005 shows that Jules has the project set up to use the multi-threaded (non-DLL) libraries. That’s always worked well for me in both VS 2003 & VS 2005.

5

The static libraries have also worked well for me in the past. However I have code which is critical to my application that needs to use the C++ Standard Library. The C++ STL isn’t exactly bleeding edge so I guess I’m a little surprised that no one has bumped into this issue before…

6

As far as I know, you can use the STL with static libraries. But if for some reason you do need to use the DLL libs, you’ll need to recompile Juce so that it also uses that option.

7

That’s what I tried. It seems to work fine in Release mode but linking is problematic when I try to build a Debug version of my application.

8

Well if there’s a link problem, it’s probably just because the two things you’re trying to link don’t have the same settings. Maybe you changed the release settings but not the debug ones or something like that.