2

So at the start of my application I call

signal(SIGPIPE, SIG_IGN);

which I thought would have my application ignore SIGPIPE. However I still got a SIGPIPE crash with the following code:

write(fd, outgoingStr->c_str(), size);

where fd is an int (file descriptor) and size is the size of the string. What am I doing wrong here?

On a side note, I recently use to wrap that write inside an if to check for an error value returned and I believe I never had SIGPIPE crashes until that was removed. The if check did nothing but cout to the console if there was an error, so I'm not sure if it is relevant or not.

Josh Brittain
  • 2,162
  • 7
  • 31
  • 54
  • 1
    You are sure you're getting a SIGPIPE? E.g. what evidence do you have that it is a signal, and not some other error? – Tony K. Oct 15 '12 at 04:01
  • Are you sure your former wrapper did nothing but write to console e.g. also exit or something? You should be getting EPIPE on the write. – Duck Oct 15 '12 at 04:03
  • gdb told me it was SIGPIPE, and pointed to the write call as the problem. The old wrapper did not exit as my program should just ignore writing on a disconnected socket. This is of course hard to test as the SIGPIPE error only happens randomly when the client doesn't exit nicely. – Josh Brittain Oct 15 '12 at 04:30
  • You should check for EPIPE on the write, close the socket and do whatever is appropriate beyond that. It shouldn't be that hard to write a test client that barfs or dies before closing its connection to the server. – Duck Oct 15 '12 at 04:48
  • 1
    It seems unlikely, but maybe some library function is restoring SIGPIPE to DIG_DFL. Run it with strace and see if the signal handler is being changed. – Barmar Oct 15 '12 at 05:51
  • I ran strace and didn't see anything messing with SIGPIPE. – Josh Brittain Oct 15 '12 at 06:38

1 Answers1

2

The problem ended up being that GDB will stop on SIGPIPE even if it is being ignored. When running the application normally it works as intended.

Josh Brittain
  • 2,162
  • 7
  • 31
  • 54