Bitcoin daemon crashes on first block download

I’ve also had the same Heisenbug for a long time with a similar setup, and I think I’ve found a workaround.

I’ve been accumulating datfiles on and off for years on a particular laptop, always kept up to date using precompiled bitcoind binaries, so I’ve been having the same problem across various bitcoind versions for a while. If you have a large number of blocks to download and check, your synchronization will most likely, but not always, segfault. You could run the daemon, let it accumulate about a month’s worth of blocks, then stop and restart it normally to bootstrap until it reaches the current chip while avoiding the segfault, but that’s not ideal.

My laptop has two (internal) SSDs, one with the executable and config files, and the other with the data directory, so I specify the data directory in the config file.

I think it’s either a hardware failure or a corrupted data file somewhere. After running memtest86 (32GB RAM) and excluding the RAM, I deleted the datadir for a fresh run with v28.0, but the same segfault occurred (never at the same point of download and validation, and usually contains up to 300k, 400k, or 500k blocks, and I have no intention of bootstrapping on/off from there!).

I tried gcc compiling the source tagged with v28.0 --disable-wallet See if it makes a difference. I tried compiling Bringing Edge Master with and without a wallet. Each executable file segmentation faulted at some point during its first download (e.g., 9 hours). I didn’t get anything from strace. One time, when I ran it with gdb, I got a segmentation fault. /usr/include/c++/14.2.1/bits/hashtable.h:2071

But I really doubt it was a problem with the C++ standard library.

Anyway, I subsequently compiled v28.0 using Clang instead of gcc and this problem did not occur again.

Precompiled binaries are compiled using gcc.