Segfault on second getMessage() call after EAGAIN error

[kdeme]

The handler (with getMessage()) where this happens is: https://github.com/status-im/nim-eth-p2p/blob/master/eth_p2p/discovery.nim#L243

I think segfault will occur because of following flow:

1. Error (EAGAIN in this case) occurs on recvfrom in readDatagramLoop and setReadError is ran.
2. A raise transp.getError() is done in getMessage or peekMessage in the transport function (see handler above).
3. Next time the handler is ran for this DatagramTransport the segfault will occur at getMessage.

Why EAGAIN happens, I don't know.

So far, I can only reproduce this (not 100% of the time) by running: https://github.com/status-im/nim-eth-p2p/blob/master/tests/tshh_connect.nim

This was tested only on a Linux x86_64 machine.

[cheatfate]

I need to understand when EAGAIN happens, at the end or in process?

[kdeme]

in process, the err var here contains it:

And then it gets raised by the getMessage call in the handler. The segfault happens only later on a second getMessage.

[cheatfate]

But why you are trying to perform one more getMessage()?

[kdeme]

I don't. It gets called automatically by the handler on next data received by same DatagramTransport.

[kdeme]

I think I found the root cause of my EAGAIN error. It is due to a poll() in an async proc (which is not nice anyhow, but that was not the point).
If you look at the poll() code it makes sense that this can happen, although it requires some conditions.

A "normal" poll() which adds the async proc with the poll() inside to the callbacks and next also the readDatagramLoop handler on an Event.Read . processCallbacks must run first the async proc with poll(). Next in that poll again Event.Read for same socket, processCallbacks runs again, both callbacks are run ... et voila, EAGAIN

So I guess this can be closed, but perhaps some documentation could be added that this should not be done.