You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mikko from codenomicon reported occasionally seeing SIGPIPE as an unhandled signal in s2nd. SIGPIPE can be generated when we try to write() to the remote end and the remote end has closed. I don't think that libs2n should mask this; our design is to emulate POSIX read()/write(), but we need s2nd and s2nc to be more tolerant of this. Instead of receiving the signal, it would be better to handle the error in the normal ways, with write() or read() returning negative values (or EOF for read()).
This change modifies s2nd and s2nc to ignore SIGPIPE rather than
have it as an unhandled exception (which exits the process).
This problem was reported by Mikko at Codenomicon. Fixes#69
Additionally this change also modifies our "return -1" cases
to exit(1), since these occur in main().
Mikko from codenomicon reported occasionally seeing SIGPIPE as an unhandled signal in s2nd. SIGPIPE can be generated when we try to write() to the remote end and the remote end has closed. I don't think that libs2n should mask this; our design is to emulate POSIX read()/write(), but we need s2nd and s2nc to be more tolerant of this. Instead of receiving the signal, it would be better to handle the error in the normal ways, with write() or read() returning negative values (or EOF for read()).
Following patch suppresses SIGPIPE:
The text was updated successfully, but these errors were encountered: