Re: "broken pipe", but not when debugging...

Graham Cox

On 11 Aug 2017, at 10:18 am, Jens Alfke <jens@...> wrote:

For some reason lost in ancient Unix history, if you write to a file-descriptor that’s been closed at the other end, a SIGPIPE signal is raised. This will by default kill your process. It’s annoying behavior but it’s long been standardized so it can’t be changed.

This doesn’t happen when run under the debugger because part of the debugger’s job is to catch all signals from your process, and I assume the debugger just ignores SIGPIPE.

OK, makes (some) sense, thanks. I’m wondering why the file descriptor would be ‘closed at the other end’ though - does that mean one of us (the command line tool is not my code but I am compiling from source) is doing something wrong? Or is it normal to close a file descriptor? The communication seems to work otherwise.

Traditionally the workaround has been to call signal() to install a process-wide no-op handler for SIGPIPE, but on Apple platforms (and others?) you can also set a flag on the file descriptor telling it not to raise the signal. I was going to write that it’s an option to setsockopt, but then I remembered you’re using a pipe not a socket. So I’m not sure what system call you’d use; ioctl maybe?

OK, I’ll look into doing something like this.


Join to automatically receive all group messages.