Handle SIGABRT

[dulive]

Hello,

considering that mptcpd uses ell shouldn't it also handle the SIGABRT signal, since ell, for example, calls abort() when an allocation fails?

[ossama-othman]

Would the goal be to abort() gracefully? As far as I know, the abort can only be prevented if the SIGABRT handler doesn't return, but if it doesn't return mptcpd realistically would be unable to do anything else. On the other hand, if the SIGABRT handler returns the abort() will end up continuing, ultimately terminating the process.

I think the general consensus is that there isn't much point in having a program attempt to fail gracefully in an out-of-memory case since there isn't much that can be done when that happens. In ELL's case, it does log the memory allocation to stderr prior to calling abort(), so at least there is some indication of why the abort() happened.

[dulive]

Would the goal be to abort() gracefully?

Yes it would.

I think the general consensus is that there isn't much point in having a program attempt to fail gracefully in an out-of-memory case since there isn't much that can be done when that happens. In ELL's case, it does log the memory allocation to stderr prior to calling abort(), so at least there is some indication of why the abort() happened.

That makes sense, I probably shouldn't have used ELL as the example.

But what if a plugin calls abort()? I'm seeing this from the perspective of a security focused plugin, where if someone uses one and it has some kind of error or if some important verification fails while processing an event, it is no longer able to guarantee the secure usage of MPTCP, and thus, mptcpd should be aborted.

Or should a plugin do it using another way?