Sumatra’s job is mostly to render complex document format. It’s fast enough to be used as a regular build. I have a configuration with ASAN enabled. At a very small performance cost it can detect if you over-write memory or try to read uninitialized memory. Was added in some point release of Visual Studio 2019. ASAN ( Address Sanitizer), is fantastic.

Run those occasionally and fix the errors and warnings

static code analysis: max level of warnings in C++ compiler, make warnings into errors, Visual Studio’s `/analyze’ option, cppcheck, clang-tidy, GitHub’s CodeQL.

Implementation was trivial: logging app creates a named pipe, logger opens the pipe (like a file) and if open succeeds, it means the logger app is running and it reads the logs we write to the pipe With separate logging app, SumatraPDF is logging all the time and when it detects that logging app is running, it’ll also log to it. This is perfect because most of the time I don’t care about the logs but when I do, I don’t want to restart the app to enable logging.

I also have an option to log to a file and I’ve recently added logging to a separate logging app via named pipe. My tiny logging module logs to a block of memory.

When investigating issues it helps to know what sequence of events led to a crash. Trust me: there’s no amount of testing you can do yourself that would match all the different things that a thousand people will do just by using the app. I wrote wrote my own assert-like function which I enable in non-debug pre-release builds so that I automatically get bug reports from people hitting those conditions. If they’re not, something went wrong and you should investigate. asserts are well established practice in C++ code: an additional code only executed in debug builds that verifies some conditions are true. Once you have crashes, look at them occasionally and try to figure out what went wrong and fix it

On the server, process those files and generate web pages for easy viewing of the crashes. Briefly: setup exception handlers to catch crashes in the app, in crash handler download symbols from the server to get readable callstack, create a crash report that includes callstacks of all thread, program and os information, log and submit that to a server. Unfortunately it’s a pain to build but this is single most important thing you can do to improve quality of your software. Step through newly added code in the debugger, verify the newly added functionality works as expected and in general use the app a lot

Sumatrapdf edit pdf