I was observing some intermittent segfaults of feature_dbcrash
with my debug build, where just after submitblock was called (and
a block was connected): a CValidationInterface was having its
vtable pointer nulled out just as it attempted to execute one of
its background slots (such as UpdatedBlockTip, BlockConnected).
This seems to be the explanation: the boost signals2 system allows
disconnections to happen concurrently with slot execution, thus
the UnregisterValidationInterface can complete and `sc` can go out
of scope while one of its slots is running. There seems to be a very
tight race involved here, visible due to the debug build slowdown,
and because feature_dbcrash does thousands of submitblock calls.
(It's not quite as tight as just calling an empty function: for each slot
call, there are something like 8 wrappers in between when the
disconnection could be noticed, and when the CValidationInterface
method is actually called.)
https://www.boost.org/doc/libs/1_55_0/doc/html/signals2/thread-safety.html