Crash in release mode with latest build

I’m getting a crash when running my app in release mode, since I got the latest juce build yesterday.
The crash I’m getting is :
Unhandled exception at 0x010ce981 in MPC-V.exe: 0xC0000005: Access violation.
in line 318 in juce_DocumentWindow.cpp (lookAndFeelChanged), which might be unrelated since it seems to be rather a heap corruption.
In debug mode, the app runs fine.
Has anybody else experienced odd behavior in release mode with the latest build? Any idea what it could be?

I’m using the latest tip, Windows 7 64-bit and 32-bit, and I am not crashing in either build. My application uses a DocumentWindow as its main window.

yeah, the Juce demo project works fine in release as well. My app is based on the Standalone plugin wrapper. It worked fine with the last version of juce (1.51), but apparently there have been quite a few changes since then, and I can’t seem to get my head around what’s going on.

turn symbols on, run it through the debugger, maybe you get a callstack. You can also try to go stepwise back though the juce-releases (;a=summary) and look which runs fine, and see whats changed.

a typical problem when you have a crash in release build and not in debug-mode are uninitialised variables (or through optimization)

the crash happens even with optimization turned off. My variables aren’t initialized in Debug mode either. I obviously also got a call stack (see above), but since it seems to be a memory corruption, the crash location is not very telling. Any other thoughts?

You’re not calling deleteAllChildren() on the document window, are you? You may have got away with that in the past, but not any more.

no, the crash happens at startup, before I delete anything.
I noticed, that if I comment out JUCE_CHECK_MEMORY_LEAKS and JUCE_CATCH_DEPRECATED_CODE_MISUSE, I don’t get the crash, and the app seems to run and shutdown without any noticed leaks in VS.
Are those defines only supposed to work in debug mode?

Sounds like you’re doing something silly, but I don’t know what. Are you linking juce statically, or including the amalg code? If you’re doing it statically, you’re probably mixing up the release and debug builds of the library and your app.

I’m able to reproduce it with the JuceDemoPlugin project. I added the standalone wrapper code, copied the HostStartup.cpp file from the plugin host project (to start the standalone window).
Without the defines, it runs fine in release mode. I can send you the project if you want (using VS 2010 though)

If you enable those macros for some of the files in your project, and not for others, then your linked product will be completely screwed. You have to make sure ALL your files have consistent settings. Most likely you’ve pulled in some files that include juce.h via a different set of headers to the way it’s included by the other files in the project.

That’s not the case either though. I checked, I’m not including juce.h anywhere in the project.
On a side note, it would be nice to have a working example of the standalone wrapper in the JuceDemoPlugin project. Any chance you can include that?

No, I think my suggestion is probably right. The HostStartup file includes juce.h from its own directory, so it’s probably got all kinds of different config settings to the ones in your app. You need to check exactly where every file in your project includes its juce.h, and make 100% sure that each of them is pulling its configs from the same file.

It’s an annoying problem, because I can’t think of any way to add some kind of warning or assertion that’ll alert you if you try to link two different files that were built using differently-configured (and therefore incompatible) juce classes. You’ll notice soon enough that your app crashes, but it’d be nice if there was a way to automatically make it clear what the problem is.

I had replaced the juce.h include in HostStartup.cpp with JuceHeaders.h, and those don’t include juce.h either. I can’t find any inclusion of juce.h anywhere in the project.

Ok, well I still think that’s the most likely cause, but if you can find any other clues, let me know!