Quote:
Quote:
- On top of this, make a built-in continue-on-crash behavior which logs the error and just resumes processing. If more crashes occur in a short amount of time (I'm setting it at 10 per 10 minutes), go to the restart behavior. Reason: A crash is either recoverable (in which case no further crashes will occur, maybe one in some cases), or it's not and then it will keep crashing continuously.
Compile a debug version with runtime checks enabled, for starters. Yes, a debug version might run slower (or faster) and differently, so it may not be found. This harkens back to proper exception handling, not exception swallowing. Present a "layman's terminology" message, and include the capability of reporting the call stack to you by prompting the user to "send crash report to developer", or something like that.
I
always test with debug versions - but have never seen this crash that Bojcha had. The debug version runs at about 1/10th of the speed of the release version so it's completely unusable (at least when using a complete preset), you cannot run it in real time. There are lots of asserts in the code to check all kinds of things that could go wrong and might not be noticed immediately. I have also analyzed both the debug and the release version with Valgrind on Linux and DrMemory on Windows, both show no warnings at all (except during startup or when opening a file, and those warnings are in Windows code, for example the open file dialog).
Reporting the call stack seems to be impossible in release version, but if an exception occurs I do log the exception code, in which filter and thread it happens, the memory location of the crash and if it's a memory error, the location of memory that it tried to read from or write to. So at least I will know where to look.
I'll also look at static analysis tools (just found something called cppcheck that I will test).
Edit: Hm, useful tool! It did find a few things - nothing major though. But it allowed me to remove some code that was not doing anything, and some other minor things.
Edit: O one major finding - but only when you have the RF display enabled (which is normally only the case during testing, since it increases the CPU load and has no effect on audio).