I agree. However, in our case, that pain has proven to be less than not having those minidumps.

Oh for me too, but I wish it was easier, like something supported seriously by my language of choice, my OS of choice or my libc of choice, with the flick of an flag... I don't retest the whole libc and kernel every time (although, err, someone should, right? :-)

Joran from the TigerBeetle team here!

TigerBeetle uses Deterministic Simulation Testing to test and keep testing these paths. Fuzzing and static allocation are force multipliers when applied together, because you can now flush out leaks and deadlocks in testing, rather than letting these spillover into production.

Without static allocation, it's a little harder to find leaks in testing, because the limits that would define a leak are not explicit.

Can you provide some pointers regarding the simulation testing for more information?

Sure!

Here's an overview with references to the simulator source, and links to resources from FoundationDB and Dropbox: https://github.com/tigerbeetledb/tigerbeetle/blob/main/docs/...

We also have a $20k bounty that you can take part in, where you can run the simulator yourself.