atilaneves
commented
1 year ago Memory corruption = all bets are off. Trying to handle it or print anything will likely make the problem worse, since there's no way to know what caused the corruption to begin with. Other than asan/valgrind/static analysis, the only way around it is a debugger.
I'm not going to limit the use of the GC in a unit testing library.
That is very hard to show all cases because GC in silly and UT makes results probabilistico on manual memory managment issues. One diffence between silly and UT is a the probabiliy one can see some informative output without digging into some core dumps.
Another one, is probability to pass tests that have memory corruption. Less GC, simplier library, less memory: more chanse to catch bug. Ofcourse, the is reliable way to use sanitazers. I am arguing about how the test engine is informative without using additional tools.
What one will see (Linux/Macos) with UT is
With silly I could more frequently see stack traces.