Menu
▾
▴
#148 SIGPIPE in evbuffer_write_iovec
See the attached log & stacktrace. Doing nothing fancy in my application - I just have to use wget instead of firefox to do a GET request, answered by a 303 redirect - so I suspect a race-con.
It may very well be an application "bug" which triggers this, but as valgrind reports no memory errors and my application is not multi-threaded I believe even if I am somehow responsible libevent should behave more graceful here.
USE_DEBUG log & stacktrace
You pretty much want to ignore SIGPIPE: it happens whenever you write on a socket that has already been closed by the other side.
The libevent unit tests all have this stanza in their main():
#ifndef WIN32
if (signal(SIGPIPE, SIG_IGN) == SIG_ERR)
return 1;
#endif
I'd recommend that for now, you go with this solution and handle the error at write()-time. Arguably, Libevent should do this itself, but I'm worried enough about hard-to-forsee compatibility issues with existing apps that I wouldn't want to try it before 2.1.x.
This should also be better documented; any documentation patch would be most welcome.
On BSD there is SO_NOSIGPIPE. on Linux there is MSG_NOSIGNAL.
You're out of luck on Solaris but I suppose developers targeting said system should know about their misfortune and already have SIG_IGN set. :-)
I'm going to close this for now as "wont fix"; if you want to write a documentation patch to explain this better, that would be great, but having to do _something_ about SIGPIPE is pretty much obligatory for the portable unix net programmer.
[Bufferevents can't use MSG_*, I think, since those are only available for send/secv, right? And on unix for scatter-gather we need to use readv/writev.]
We could set the signal handler to SIG_IGN by default, but I'm worried that doing that that would somehow break existing code.