I’m doing most of my work on Mac/Linux. However I’ve ported an application to Windows, which runs as excepted as a debug build but outputs no signal when compiled as a release build. On Mac or Linux I’d probably start printing some variable states from within the DSP callback with printf to get an idea what’s going on, however a Windows GUI application gives me no console per default.
Before I start to create a console for this purpose (I know this is possible) - is there any quick way or neat trick to debug a release build in Visual Studio I’m not aware of?
You can use Juce’s Logger::writeToLog which will on Windows use the OutputDebugStr API instead of printf. Then if you start debugging (even a release build) in Visual Studio, those messages can be seen in the “Output” pane of VS. Alternatively you can use the DebugView.exe program to view the messages from OutputDebugStr calls. Obviously you should be very careful when outputting messages from within the audio processing thread, things can get clogged up and you may get side effects that just make it harder to understand your original problem.
You can tell Visual Studio to compile a release build with Debug variables.
That means: you can look at the value of variables, even when in Release build.
There is an option for this in the Projucer. See attached screenshot. Or else you can activate it directly from within Visual Studio.
Release configuration only bugs are usually due to uninitialized variables. The Debug runtime zeroes all memory before its usage, but the Release runtime doesn’t and you usually get garbage. Depending on the size of the project, it might not be feasible to inspect every variable creation, but the more you use auto and in-class member initialization, the safer it becomes.
Further to this, uninitialised variables on Windows will often be uninitialised on Mac/Linux too, so you might be able to track them down with Undefined Behaviour Sanitizer on one of those platforms.
Like it or not, it’s valid C++ so it will compile. I assume you’re building with warnings enabled and “warnings are errors” selected. In this simple case the compiler can tell that it’s an uninitialised variable, but if you make it more complicated then the compiler can miss these things.
Wow, this discussion got quite far since my initial post yesterday
Anyway, you all shared a lot of interesting input, but mainly @Xenakios first answer was the solution to my question.
By the way, it turned out that the error was not based on an uninitialized variable but on the mis-use of a third party API which I could indeed spot with some print-debugging