Segfault at block 1062 on Linux headless

[Bananajoe97]

hey, linux headless node segfaults every time at block 1062 (hash 540770880b2ee2). built from repo with build-linux.sh on ubuntu 24.04, ryzen 9 7900.

the node connects fine via nostr (nos.lol), starts receiving blocks, then crashes at block 1062 with "Segmentation fault (core dumped)". same crash every restart, 100% reproducible.

received block:
CBlock(hash=540770880b2ee2, ver=1, hashPrevBlock=29aa092cafb5f9, hashMerkleRoot=835ed0, nTime=1785068831, nBits=1e3260a9, nNonce=11027, vtx=2)
Segmentation fault (core dumped)

solomine mode works fine, the crash is only when syncing the main chain. thanks for the project btw, cool concept 👍

[Vic-Nas]

You can check out my pull request.
But I focused more on the gui app than the command line so it might be finicky.
It does work on linux though.

[Bitflash-sh]

Reproduced exactly, root-caused, and already fixed — details below so you can confirm on your side.

Reproduction

I built the commit that was repo tip when you filed (56df983, dated 2026-07-24) on Debian 13 / x86_64 with build-linux.sh, and ran it under gdb against the live network. It died on your block, byte for byte:

CBlock(hash=540770880b2ee2, ver=1, hashPrevBlock=29aa092cafb5f9, hashMerkleRoot=835ed0, nTime=1785068831, nBits=1e3260a9, nNonce=11027, vtx=2)

Thread 6 "bitflash-node" received signal SIGSEGV, Segmentation fault.

1062 blocks received, then dead. Same hash, same vtx=2.

Root cause

Not the block, and nothing to do with validation. It is the logging of the block.

#3  vsnprintf () from /lib/x86_64-linux-gnu/libc.so.6
#4  strprintf (format="CTxOut(nValue=%I64d.%08I64d, scriptPubKey=%s)") at util.cpp:144
#5  CTxOut::ToString() at main.h:354
#6  CTransaction::ToString() at main.h:596
#7  CBlock::print() at main.h:1022
#8  ProcessMessage (strCommand="block") at main.cpp:1993

%I64d is an MSVC-only format specifier, inherited from the Bitcoin 0.1.0 codebase, which was written for Visual C++. glibc does not implement it. It parses it as the GNU I flag, a width of 64, and a d conversion — so it reads an int where an int64 was passed.

The block that survived immediately before yours shows the damage in plain sight:

CTxOut(nValue=                                                              50.%08I64d, scriptPubKey=(null))
              ^-- "50" padded to width 64                                     ^ literal  ^ wrong vararg slot

%08I64d comes out verbatim because I after a width is not valid, and by then vararg consumption is desynchronised — so %s reads the wrong slot. On a coinbase-only block that slot happened to be NULL, and glibc prints (null) rather than crashing. Block 1062 is the first block on the chain with vtx=2, so it is the first one whose slot holds a non-NULL garbage pointer, which %s then dereferences. That is why it is 100% reproducible and always the same block rather than intermittent.

Minimal confirmation, no Bitflash involved:

int64_t a = 50, b = 0;
snprintf(buf, sizeof buf, "CTxOut(nValue=%I64d.%08I64d, scriptPubKey=%s)", a, b, "76a914...");
// → Segmentation fault

Your -solomine run was on the same code path (main.cpp:2354 also calls pblock->print()), so it was luck of the values, not a safe path.

Worth adding: the compiler had been saying so the whole time.

warning: format '%d' expects argument of type 'int', but argument 4 has type 'int64_t'
   %I64d
       int

The build uses -w, which suppresses that. I am going to change that separately — a format-string bug that segfaults a node is exactly what those warnings exist to catch.

Fixed

The specifiers were changed to %lld in the refactor that landed shortly after you reported. First release containing the fix is v1.1.0 (tagged 2026-07-27, the day after you filed); your build predates it by three days. %I64d is gone from main.h, net.h, db.cpp and util.cpp as of that release. The only remaining hits in the tree are inside vendored ImGui, correctly guarded by #ifdef _MSC_VER, and not linked into the headless node at all.

Verified on current v1.2.4, same Debian box, fresh datadir: sailed through 540770880b2ee2 at height 1062 and kept going to 2663 with ProcessBlock: ACCEPTED throughout and no crash.

What to run

build-linux.sh no longer exists. v1.2.4 ships a prebuilt headless binary that needs no libGL and no FUSE:

wget https://github.com/Bitflash-sh/bitflash/releases/download/v1.2.4/bitflash-node-1.2.4-x86_64
chmod +x bitflash-node-1.2.4-x86_64
./bitflash-node-1.2.4-x86_64 -nogui -gen

One caveat for your Ryzen 9, since you will want it: -gen did not actually mine on headless builds from v1.2.0 through v1.2.4 — nMineMode stayed at MINE_RELAY and the miner returned immediately without logging anything. That is #42, fixed but not yet released. Until it ships, a headless node syncs and relays but does not mine, so do not judge your hashrate from a v1.2.4 run.

Closing as fixed. Thank you for the report — the block hash and the "same every restart" detail are what made this a twenty-minute diagnosis instead of a hunt, and the underlying lesson (a suppressed compiler warning sitting on a crash) is worth more to the project than the fix itself.