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