i’ve had this identical heisenbug for a longtime with an identical setup and suppose have discovered a workaround:
i have been accumulating datfiles on and off for years on one explicit laptop computer and have been having the identical drawback throughout totally different bitcoind variations for some time utilizing precompiled bitcoind binaries, at all times saved updated. if there are a number of blocks to obtain and confirm, it’ll most occasions, not at all times, segfault effectively into syncing. i might run the daemon, let it accumulate a couple of months’ price of blocks, then cease it usually and restart it, and bootstrap my option to the present tip like that avoiding segfaults, however that is not preferrred.
the laptop computer has two (inner) ssd’s, the executable and conffile are on one, and the datadir on the opposite, therefore i specify the datadir within the conf file.
i suspected {hardware} failure or corrupt datfile someplace. after working memtest86 (32gb ram) and ruling out ram, i deleted the datadir for a contemporary run with v28.0, however received the identical segfaults (by no means on the identical level within the obtain and verification, normally ~300k, 400k or 500k blocks in, and i am not going to bootstrap on and off from there!).
i attempted gcc compiling supply tagged v28.0 with --disable-wallet to see if that made a distinction. i attempted compiling bleeding edge grasp additionally with and with out pockets. every executable segfaulted in some unspecified time in the future effectively into the preliminary obtain (eg 9hrs). by no means received something from a strace. on one event i ran it underneath gdb and it segfaulted at /usr/embrace/c++/14.2.1/bits/hashtable.h:2071
nonetheless i actually doubt it was a problem within the c++ customary library.
anyway, i then compiled v28.0 utilizing clang as a substitute of gcc, and have not skilled the issue once more.
the precompiled binaries are compiled utilizing gcc.
