Failed jasserts should crash debug builds even when debugger is not attached


#1

Hi,

I was surprised to find out that JUCE assertions (jassert) only trigger a crash when attached with a debugger. I’d like debug builds to informatively crash on assertion failures even when a debugger is not attached. This would allow in-house testers to run Debug builds which crash on assertions failure without requiring them to attach a debugger (the testers might not even have a development environment installed).

The standard assert already works this way, and calls abort() in debug builds regardless of whether a debugger is attached.

If you agree this is something useful to have, I can think of three options:

  1. Just change the existing behavior so that jassert always aborts in debug builds, not just when a debugger is attached.
  2. Same as 1 but add an opt-out macro to revert to the existing behavior (only crash on failed assertion under debugger).
  3. Add an opt-in macro to turn on the new suggested behavior.

I had thought option 1 is the best, since if you have have debug builds which fail assertions, it’s better they trigger a crash than silently fail. Then I noticed a failed jassert outputs a log without crashing in debug builds, and maybe that’s a behavior that would sometimes be useful, although probably less often. So now I think option 2 makes the most sense.

Thoughts?

Thanks,
Dan


#2

I have a strong opinion against option 1 (change to always abort), but I think an opt-in with a macro could be useful.
However, what does an abort help, if you don’t have a debugger attached in the first place?
Ok, collecting a stack-trace could be, what you are after…


#3

Finding out about the failed assert (either know to query the machine’s log and/or have the failure message also outputted in the crash report) instead of it failing silently on the testing machine. And yes, getting a stack trace.

Those are the technical things I’m after; the high-level purpose is to find out about problems during development, when running debug builds on in-house testers’ machines.


#4

Would appreciate a follow up from the JUCE team.

Thanks,
Dan


#5

I was about to reply and say that it’s easy enough to make it terminate by using the JUCE_LOG_CURRENT_ASSERTION macro, but actually it’s not set-up to allow you to customise the behaviour of that macro…

What I can do very easily and non-controversially is to push a change so that if you set your own definition for that macro it’ll be used, and then you can make the assertions do whatever you like.


#6

I guess that would allow for even more flexibility, but I still think the default behavior that would be expected by most programmers and testers is for debug builds to terminate on failed jasserts, even when not attached to a debugger, same as with the standard assert. So I think adding this macro to configure the default behavior, and expose it in the projucer, without having to go the extra mile and have a fully customized jassert, would be useful.

If it’s too controversial to make this the default behavior right away, perhaps we can add an opt-in for this behavior right now, and gradually migrate to it being the default? For example, make the opt-in macro available now and make it configurable in the projucer but checked out by default. In the future make it checked in by default. And possibly sometime later after that, remove it and make it always on if everyone agrees that’s the expected behavior.