[Crash/Fuzzing] segmentation fault during state transition (process_final_updates)
pventuzelo opened this issue · 2 comments
pventuzelo commented
During fuzzing, I triggered a segmentation fault
in state transition processing. Based on gdb, issue come from process_final_updates
.
Reproducing
branch: devel
commit: 65ca74c
Download:
segfault_transition_process_final.zip
$ make
$ cd ncli
$ ../env.sh nim c -d:const_preset=mainnet ncli_transition
$ ./ncli_transition --pre= segfault_transition_process_final_beacon_nimbus_devel.ssz --blck= segfault_transition_process_final_block_nimbus_devel.ssz --post= segfault_transition_process_final_beacon_nimbus_devel.ssz
[1] 29114 segmentation fault ./ncli_transition --pre= beacon-pre.ssz --blck= block-crash.ssz --post= beacon-pre.ssz
GDB
$ gdb --args ./ncli_transition --pre= segfault_transition_process_final_beacon_nimbus_devel.ssz --blck= segfault_transition_process_final_block_nimbus_devel.ssz --post= segfault_transition_process_final_beacon_nimbus_devel.ssz
[...]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
process_final_updates__lKFDgP7VBTZCZIy9a9b589cTw_3 (state=state@entry=0x7fffffd6d580)
at XXX/nim-beacon-chain/beacon_chain/spec/state_transition_epoch.nim:379
379 func process_final_updates*(state: var BeaconState) {.nbench.}=
(gdb) bt
#0 process_final_updates__lKFDgP7VBTZCZIy9a9b589cTw_3 (state=state@entry=0x7fffffd6d580)
at XXX/nim-beacon-chain/beacon_chain/spec/state_transition_epoch.nim:379
#1 0x00005555556a2151 in process_epoch__lKFDgP7VBTZCZIy9a9b589cTw (state=state@entry=0x7fffffd6d580)
at XXX/nim-beacon-chain/beacon_chain/spec/state_transition_epoch.nim:451
#2 0x00005555556a5f31 in process_slots__qihLKyAUoREyhTUi9b9cAKJQ (state=state@entry=0x7fffffd6d580,
slot=<optimized out>)
at XXX/nim-beacon-chain/beacon_chain/state_transition.nim:249
#3 0x00005555556aca9f in state_transition__o10Cn5E9cwiqw303qyIywww (state=0x7fffffd6d580,
signedBlock=0x7fffffadcfe0, flags=<optimized out>)
at XXX/nim-beacon-chain/beacon_chain/state_transition.nim:263
#4 0x00005555556ad1bf in CLI__pSFxEjrp6Wmf3rE51bmZ9cg (pre=0x7ffff7f54678, blck=0x7ffff7f57438,
post=0x7ffff7f54938, verifyStateRoot=<optimized out>)
at XXX/nim-beacon-chain/ncli/ncli_transition.nim:13
#5 0x00005555556aec33 in NimMainModule ()
at XXX/nim-beacon-chain/vendor/nim-confutils/confutils.nim:981
#6 NimMainInner ()
at XXX/nim-beacon-chain/vendor/nim-serialization/serialization/errors.nim:83
#7 0x00005555556b09c2 in NimMain ()
at XXX/nim-beacon-chain/vendor/nim-serialization/serialization/errors.nim:91
#8 0x000055555555677d in main (argc=<optimized out>, args=<optimized out>, env=<optimized out>)
at XXX/nim-beacon-chain/vendor/nim-serialization/serialization/errors.nim:98
tersec commented
Separately from the PR linked, this test case also drives the state_transition(...)
machinery from slot 0 to slot 65537, which simply takes a while, but that's functioning as designed as far as I can tell.