The SEGV does not occur always. And especially not when Eth2Node.stop(): timeout reached, which would be cases where not all the shutdown code is run (for example, the transports closing).
There is an importance here on fixing this SEGV, as the databases are closed after the closing of the network. (or we just move or remove the network shutdown for now)
edit: Testing this with gdb shows that the segv happens in securedHandler.
On dde973e2d432482414ac7565618f912a99feccc5 (unstable), but I haven't tested with stable, might occur there too.
First quick investigation indicates that it is in https://github.com/status-im/nimbus-eth2/blob/dde973e2d432482414ac7565618f912a99feccc5/beacon_chain/eth2_network.nim#L1173 More specifically when running https://github.com/status-im/nim-libp2p/blob/87be2c7f1f4a161a6a2fb2cccc20062c9595f01f/libp2p/transports/tcptransport.nim#L155. At least, commenting that out makes the SEGV go away...
The SEGV does not occur always. And especially not when
Eth2Node.stop(): timeout reached
, which would be cases where not all the shutdown code is run (for example, the transports closing).There is an importance here on fixing this SEGV, as the databases are closed after the closing of the network. (or we just move or remove the network shutdown for now)
edit: Testing this with gdb shows that the segv happens in
securedHandler
.