I am a Ph.D. student in computer science and my research topic is software dependability. Currently I am doing some experiments to study an application's resilience with respect to system call invocation errors. For example, I find that when a futex system call invocation fails with error ENOMEM (insufficient memory), geth directly crashes and output the following information (full log could be found here):

futexwakeup addr=0xc000059550 returned -12
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x1006 pc=0x44b26b]

runtime stack:
runtime.throw(0x1361858, 0x2a)
    runtime/panic.go:1117 +0x72
    runtime/signal_unix.go:718 +0x2e5
runtime.futexwakeup(0xc000059550, 0x1)
    runtime/os_linux.go:68 +0x8b
    runtime/lock_futex.go:144 +0x45
runtime.startm(0x0, 0xc41eb856d14b6201)
    runtime/proc.go:2397 +0x1b9
    runtime/proc.go:2477 +0x66
runtime.ready(0xc002790f00, 0x3, 0xc0ba753501)
    runtime/proc.go:790 +0xb6
    runtime/proc.go:347 +0x38
    runtime/asm_amd64.s:379 +0x66

goroutine 9468 [running]:
goroutine 9416 [select]:
    github.com/ethereum/go-ethereum/p2p/peer.go:278 +0x125
created by github.com/ethereum/go-ethereum/p2p.(*Peer).run
    github.com/ethereum/go-ethereum/p2p/peer.go:232 +0x125

My question is do you think the developers of go-ethereum need to design some error handling mechanisms for system call invocation errors, or this is something related to the go library?

I haven't used go before. I am wondering if it is possible to retry since some of the errors such as ENOMEM rarely happen and they can be fixed by the OS later? In this case, the geth client could be more resilient facing turbulence caused by an unstable operating system.

Thanks and look forward to hearing your feedback! Have a nice day!

  • 1
    Probably it is better to ask go-ethereum developers directly, github.com/ethereum/go-ethereum. In my experience developing software at some point you trust the OS will do something reasonable with the resources. For example perhaps in case of out of memory error the better option is crashing the application to avoid data corruption. You can manage ram yourself but then you'll competing with the OS and other applications.
    – Ismael
    Commented Jul 10, 2021 at 18:27
  • 1
    Thanks @Ismael for the comment! Yeah, I also asked the same question there as an issue but the developers suggest me triggering some discussions here because they only use the issue tracker to record bugs. I agree with you that we should let the OS do its job in most cases. But sometimes I think we could still have some re-try strategies in our application, or in an orchestration framework under the condition that no data corruption happens. Otherwise, users have to restart the application manually even if some situations such as memory issues or network failures are transient.
    – gluckzhang
    Commented Jul 12, 2021 at 11:58


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.