Amaury Chamayou

To be reviewed in 3.x, if it affects historical queries in JS Generic.

It seems like isolating the nodes from each other right after posting the recovery shares should do the trick, unless I'm missing something?

Another simpler thing to do is to kill the primary shortly after the beginning of a primary recovery, and check that it finished correctly on two nodes.

It shouldn't even throw, and it should not try to terminate in a way that somehow works in any context or anything like that. FATAL is a log level, like...

Sounds good to me!

Turning on the suggested options does not reveal much more: ``` 2020-10-09T11:54:12.8473188Z 48: ==2952==AddressSanitizer: libc interceptors initialized 2020-10-09T11:54:12.8473533Z 48: || `[0x10007fff8000, 0x7fffffffffff]` || HighMem || 2020-10-09T11:54:12.8473863Z 48: || `[0x02008fff7000, 0x10007fff7fff]`...

Some potentially helpful information in here: https://github.com/google/sanitizers/issues/723 I don't believe we have any protected memory though.

Also of interest: https://github.com/google/sanitizers/issues/870 It looks like snmalloc may in fact protect some pages when built with USE_POSIX_COMMIT_CHECKS, but that's not the case for us. Let's try ASAN_OPTIONS=fast_unwind_on_malloc=0 and see...

No luck with the slow unwind: https://dev.azure.com/MSRC-CCF/CCF/_build/results?buildId=13938&view=logs&j=383d248c-4494-5797-d98f-6cef5140601e&t=bbcdfa66-260b-5619-96df-9537b476c35e Issue happens still, and running is so slow that CI times out.

https://www.chromium.org/developers/testing/leaksanitizer suggests we ought to be using a debug version of libc++: > Using debug versions of shared libraries > (NOTE: the libstdc++ part is no longer required for Chromium,...