bitcoin-qt segfault (heap write in memmove on GUI thread) when a new block connects shortly after startup #36527

Unfortunately I am not able to reproduce. This is the info I was able to get from the unexpected crashes. I'm not sure it's actionable but figured I'll report what I have:

Current behaviour

bitcoin-qt crashed twice with a segfault shortly after startup, without any user action. In both cases the crash happened in the same second that the node connected a new block (UpdateTip for height 971290), within ~15–45 seconds of startup.

On a third launch the same block connected ~1.5 minutes after startup with no crash, so the block itself doesn't appear to be the trigger. None of the loaded wallets had transactions in that block. The node has run fine since.

Kernel log:

bitcoin-qt[113346]: segfault at 600bd19d2ac0 ip 00007d168f5a0946 sp 00007fff72f25848 error 6 in libc.so.6[1a0946,7d168f428000+195000] likely on CPU 5 (core 5, socket 0)
Code: 81 fa 80 00 00 00 76 ad c5 fe 6f 56 40 c5 fe 6f 5e 60 c5 fe 6f 64 16 e0 c5 fe 6f 6c 16 c0 c5 fe 6f 74 16 a0 c5 fe 6f 7c 16 80 <c5> fe 7f 07 c5 fe 7f 4f 20 c5 fe 7f 57 40 c5 fe 7f 5f 60 c5
fe 7f
bitcoin-qt[113534]: segfault at 5f4332620540 ip 00007be49dba0946 sp 00007ffd98493c48 error 6 in libc.so.6[1a0946,7be49da28000+195000] likely on CPU 1 (core 1, socket 0)
Code: (identical)

What the crash data shows:

• Faulting instruction: libc offset 0x1a0946 resolves to __memmove_avx_unaligned_erms+262 (vmovdqu %ymm0,(%rdi)). That's a store inside memcpy/memmove.
• error 6: a user-mode write to a page that isn't mapped.
• Fault address: inside the process heap, which points to memory corruption (use-after-free or heap overflow).
• Thread: the stack pointer (0x7fff…) is on the main thread's stack, so the crash was on the Qt GUI thread.

My guess is a race between the GUI's startup setup (wallet/transaction models) and the first new-tip notification. I haven't confirmed that yet, since no core dump was captured.

Expected behaviour

No crash.

Steps to reproduce

Not reliably reproducible. Conditions in both crashes:

1. Start bitcoin-qt with several descriptor wallets loading at startup and a large mempool.dat (~68k txs).
2. A new block arrives and connects within ~15–45 s of startup (in one crash, mempool.dat loading was still in progress).
3. Crash in the same second as UpdateTip.

Possible repro: close bitcoin-qt, wait until a new block has been mined, then restart, so the block connects right after startup.

Relevant log output

In both crashed runs, the last line debug.log wrote (the rest of the file was null bytes) was:

Enabling script verification at block [#971290](/bitcoin-bitcoin/971290/) (...): block height above assumevalid height.
UpdateTip: new best=0000000000000000000115846c775bc8fd7268d129dbd3455901a8ad8243106c height=971290 ... progress=1.000000

Tor control connection failures were logged before each crash (Tor not running); probably unrelated.

How did you obtain Bitcoin Core

Compiled from source.

What version of Bitcoin Core are you using?

v32.99.0-60afa0b8d71f (master, no local changes)

Operating system and version

Linux x86_64, kernel 6.16