jassert works just like a breakpoint – your code will be halted in the debugger. I just created a stupid example in a project I’m currently working on with adding the line
jassert (1 == 2) which will of course always fail. This is what happens when I execute that code under the debugger. Note that my IDE is JetBrains CLion, so this might look different in your IDE (this is why I asked which one you use), but you’ll find the same elements in your IDE as well.
Let’s check what we are seeing here. First of all, we see the blue code line with the red flash icon beneath it in the line were I added this assertion, that tells us that we have stopped at a breakpoint here.
Whenever you halted at a breakpoint you can inspect two things, which you’ll find in the lower section.
The call stack
You find that in the bottom left corner. There you see how the code flow reached this line of code at all. For an example we see that the function
OJDAudioProcessor::prepareRessources we stopped in has been called by
jb::PluginAudioProcessorBase... which again has been called by
juce::VST3Component::preparePlugin and so on (we can even see code outside our plugin here, e.g. functions that the host called, which are greyed out here). All those steps are so called stack frames and each upper stack frames saves it variable states. More on that below…
The variable inspector
On the bottom right we see our variables. We see three bools and one const float here and we see their exact values. For structs like e.g.
spec which is a
juce::dsp::ProcessSpec we see this tiny triangle icon on the left which would open up a sub-view through which we could see the values of all members of this struct. We also see the
this pointer here, which is a way to look at member variables in the class we are currently in.
Jumping up the call stack
Now if you click on the previous stack frame in the call stack on the left you can jump into that function and you’ll see the variable states in that stack frame and all other previous functions there. This way you can usually find out very quick how a certain value reached your function.
Now in your case I’d first inspect if either
sampeRate has an unexpected value. Then I’d try to jump up the call stack and see where it came from, which will hopefully lead you to the original source of this bug. I hope this helps you a bit.