mempool_updatefromblock.py fails on 32-bit (armhf, ...)

maflcko commented at 8:52 pm on December 18, 2025: member

Steps to reproduce:

armhf metal, or via podman run -it --rm --platform linux/arm/v7 'debian:trixie'
export DEBIAN_FRONTEND=noninteractive && apt update && apt install curl wget htop git vim ccache -y && git clone https://github.com/bitcoin/bitcoin.git --depth=1 ./b-c && cd b-c && apt install build-essential cmake pkg-config python3-zmq libzmq3-dev libevent-dev libboost-dev libsqlite3-dev systemtap-sdt-dev libcapnp-dev capnproto libqrencode-dev qt6-tools-dev qt6-l10n-tools qt6-base-dev clang llvm libc++-dev libc++abi-dev -y
rm -rf ./bld-bisect/ && cmake -B ./bld-bisect -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER='clang' -DCMAKE_CXX_COMPILER='clang++' --preset=dev-mode -DBUILD_UTIL_CHAINSTATE=OFF -DBUILD_BENCH=OFF -DBUILD_FUZZ_BINARY=OFF -DBUILD_GUI=OFF -DBUILD_KERNEL_LIB=OFF -DBUILD_TESTS=OFF -DENABLE_WALLET=OFF -DENABLE_IPC=OFF -DWITH_ZMQ=OFF -DWITH_BDB=OFF -DWITH_NATPMP=OFF -DWITH_NATPMPP=OFF -DWITH_MINIUPNPC=OFF -DWITH_MULTIPROCESS=OFF
cmake --build ./bld-bisect --parallel $(nproc) && ./bld-bisect/test/functional/mempool_updatefromblock.py --timeout-factor 5

First bad commit is 47894367b583c06c53d568dc4a984d27bac8f742

 02025-12-18T20:39:45.629000Z TestFramework (INFO): PRNG seed is: 1933782243
 12025-12-18T20:39:45.630000Z TestFramework (INFO): Initializing test directory /tmp/bitcoin_func_test_b7nlv98l
 22025-12-18T20:39:47.600000Z TestFramework (INFO): Creating 100 transactions...
 32025-12-18T20:39:50.975000Z TestFramework (INFO): The batch of 25 transactions has been accepted into the mempool.
 42025-12-18T20:39:51.183000Z TestFramework (INFO): All of the transactions from the current batch have been mined into a block.
 52025-12-18T20:39:59.928000Z TestFramework (INFO): The batch of 25 transactions has been accepted into the mempool.
 62025-12-18T20:40:00.151000Z TestFramework (INFO): All of the transactions from the current batch have been mined into a block.
 72025-12-18T20:40:14.350000Z TestFramework (INFO): The batch of 25 transactions has been accepted into the mempool.
 82025-12-18T20:40:14.574000Z TestFramework (INFO): All of the transactions from the current batch have been mined into a block.
 92025-12-18T20:40:30.226000Z TestFramework (INFO): The last batch of 25 transactions has been accepted into the mempool.
102025-12-18T20:40:32.193000Z TestFramework (INFO): All of the recently mined transactions have been re-added into the mempool in 1.9641704559326172 seconds.
112025-12-18T20:40:32.194000Z TestFramework (INFO): Checking descendants/ancestors properties of all of the in-mempool transactions...
122025-12-18T20:40:34.347000Z TestFramework (INFO): Creating independent transactions to test MAX_DISCONNECTED_TX_POOL_BYTES limit during reorg
132025-12-18T20:42:25.872000Z TestFramework (ERROR): Assertion failed
14Traceback (most recent call last):
15  File "/b-c/test/functional/test_framework/test_framework.py", line 183, in main
16    self.run_test()
17    ~~~~~~~~~~~~~^^
18  File "/b-c/./bld-bisect/test/functional/mempool_updatefromblock.py", line 185, in run_test
19    self.test_max_disconnect_pool_bytes()
20    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
21  File "/b-c/./bld-bisect/test/functional/mempool_updatefromblock.py", line 175, in test_max_disconnect_pool_bytes
22    assert_equal(len(mempool), expected_parent_count * 2)
23    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
24  File "/b-c/test/functional/test_framework/util.py", line 77, in assert_equal
25    raise AssertionError("not(%s)" % " == ".join(str(arg) for arg in (thing1, thing2) + args))
26AssertionError: not(398 == 396)

maflcko added the label Tests on Dec 18, 2025

maflcko commented at 8:54 pm on December 18, 2025: member

I guess the 32-bit mempool has tighter packing, so accepts more transactions?

maflcko commented at 8:59 pm on December 18, 2025: member

Also related to #33724, I wonder if we should just give up on size_t and use u64 consistently everywhere.

All of this engineering effort doesn’t seem worth it just to allow the few armhf users to add a few bytes of more transactions to their mempool.

sipa commented at 9:06 pm on December 18, 2025: member

@maflcko Even without using platform-dependent integer sizes, there will be memory usage differences between 32-bit and 64-bit platforms due to differences in pointer size. Beyond those, malloc overhead and alignments can differ between systems as well.

maflcko commented at 10:57 am on December 22, 2025: member

That is probably right. Replacing size_t with uint64_t inside the mempool entry does not change anything here. However, setting DEBUG=1 in the std lib “works around” the issue. So it is likely that the dynamic memory overhead is different.

fanquake closed this on Jan 5, 2026

fanquake referenced this in commit 755f0900a2 on Jan 5, 2026

mempool_updatefromblock.py fails on 32-bit (armhf, …) #34108