eth_callBundle Causing Segfault

[BowTiedDevil]

Describe the bug

Since v1.1.3, calling the eth_callBundle endpoint causes reth/op-reth to panic and throw a segfault.

It segfaults on my own transactions, and from the transaction mentioned in PR #12687 which I'll use to demonstrate:

> cast rpc eth_callBundle '{"txs":["0x02f8778501a5ee289c80840e078998840e0789a6825208944be0cd2553356b4abb8b6a1882325dabc8d3013d880de0b6b3a764000080c080a0c3b6de99450a27e5bd1c4503d657e7725037e37f01ea95570545f1bb1d5ac77fa079100f752ac8ebeea043acce8f6fb37f4fa3714debeac4e3278aa2a3bf93ea4f"],"blockNumber":"'$(cast --to-hex $(cast block-number))'","stateBlockNumber":"'$(cast --to-hex $(cast block-number))'","coinbase":"0x4bE0Cd2553356b4ABb8b6a1882325dAbC8d3013D"}' | jq .

Steps to reproduce

1. Send a JSON payload to the eth_callBundle endpoint.
2. Observe node segfault

Node logs

btd@dev:~$ ./reth node --datadir /mnt/data/reth_mainnet/ --datadir.static-files /mnt/nas/node_data/reth_mainnet_static_files/ --http --http.api all
2024-12-17T05:43:04.464588Z  INFO Initialized tracing, debug log directory: /home/btd/.cache/reth/logs/mainnet
2024-12-17T05:43:04.467087Z  INFO Starting reth version="1.1.4 (15fac087)"
2024-12-17T05:43:04.467100Z  INFO Opening database path="/mnt/data/reth_mainnet/db"
2024-12-17T05:43:04.588869Z  INFO Configuration loaded path="/mnt/data/reth_mainnet/reth.toml"
2024-12-17T05:43:04.643143Z  INFO Verifying storage consistency.
2024-12-17T05:43:04.659279Z  INFO Database opened
2024-12-17T05:43:04.659420Z  INFO 
Pre-merge hard forks (block based):
- Frontier                         @0
- Homestead                        @1150000
- Dao                              @1920000
- Tangerine                        @2463000
- SpuriousDragon                   @2675000
- Byzantium                        @4370000
- Constantinople                   @7280000
- Petersburg                       @7280000
- Istanbul                         @9069000
- MuirGlacier                      @9200000
- Berlin                           @12244000
- London                           @12965000
- ArrowGlacier                     @13773000
- GrayGlacier                      @15050000
Merge hard forks:
- Paris                            @58750000000000000000000 (network is known to be merged)
Post-merge hard forks (timestamp based):
- Shanghai                         @1681338455
- Cancun                           @1710338135
2024-12-17T05:43:04.659833Z  INFO Transaction pool initialized
2024-12-17T05:43:04.660009Z  INFO Loading saved peers file=/mnt/data/reth_mainnet/known-peers.json
2024-12-17T05:43:04.660783Z  INFO P2P networking initialized enode=enode://106cfe27fb1d1ae37458f8a270526216144b32804c48c8359b2e4bd6191d9da8a5f60aad1080ce1cbaeeb73a41b5ba51c602a58d9ce6cc1535e095b3bd573c99@0.0.0.0:30303
2024-12-17T05:43:04.660877Z  INFO StaticFileProducer initialized
2024-12-17T05:43:04.661332Z  INFO Pruner initialized prune_config=PruneConfig { block_interval: 5, segments: PruneModes { sender_recovery: None, transaction_lookup: None, receipts: None, account_history: None, storage_history: None, receipts_log_filter: ReceiptsLogPruneConfig({}) } }
2024-12-17T05:43:04.661625Z  INFO Consensus engine initialized
2024-12-17T05:43:04.661681Z  INFO Engine API handler initialized
2024-12-17T05:43:04.663831Z  INFO RPC auth server started url=127.0.0.1:8551
2024-12-17T05:43:04.663998Z  INFO RPC IPC server started path=/tmp/reth.ipc
2024-12-17T05:43:04.664004Z  INFO RPC HTTP server started url=127.0.0.1:8545
2024-12-17T05:43:04.664040Z  INFO Starting consensus engine
Segmentation fault (core dumped)

Platform(s)

Linux (x86)

Container Type

Docker

What version/commit are you on?

reth Version: 1.1.4
Commit SHA: 15fac08
Build Timestamp: 2024-12-11T10:15:56.110591348Z
Build Features: asm_keccak,jemalloc
Build Profile: maxperf

What database version are you on?

Current database version: 2
Local database version: 2

Which chain / network are you on?

mainnet

What type of node are you running?

Archive (default)

What prune config do you use, if any?

No response

If you've built Reth from source, provide the full command you used

No response

Code of Conduct

• I agree to follow the Code of Conduct