i’ve had this same heisenbug for a longtime with a similar setup and think have found a workaround:
i’ve been accumulating datfiles on and off for years on one particular laptop and have been having the same problem across different bitcoind versions for a while using precompiled bitcoind binaries, always kept up to date. if there are a lot of blocks to download and verify, it will most times, not always, segfault well into syncing. i could run the daemon, let it accumulate about a months’ worth of blocks, then stop it normally and restart it, and bootstrap my way to the current tip like that avoiding segfaults, but that’s not ideal.
the laptop has two (internal) ssd’s, the executable and conffile are on one, and the datadir on the other, hence i specify the datadir in the conf file.
i suspected hardware failure or corrupt datfile somewhere. after running memtest86 (32gb ram) and ruling out ram, i deleted the datadir for a fresh run with v28.0, but got the same segfaults (never at the same point in the download and verification, usually ~300k, 400k or 500k blocks in, and i’m not going to bootstrap on and off from there!).
i tried gcc compiling source tagged v28.0 with --disable-wallet to see if that made a difference. i tried compiling bleeding edge master also with and without wallet. each executable segfaulted at some point well into the initial download (eg 9hrs). never got anything from a strace. on one occasion i ran it under gdb and it segfaulted at /usr/include/c++/14.2.1/bits/hashtable.h:2071
however i really doubt it was an issue in the c++ standard library.
anyway, i then compiled v28.0 using clang instead of gcc, and haven’t experienced the problem again.
the precompiled binaries are compiled using gcc.
