WebServerThread crashing when the session is closed

Advanced Mac OS X Programming: The Big Nerd Ranch 20. Multithreading
1

I keep getting a crash for the webserverThread example. I open up multiple sessions to test the threading / queues etc and all seems to work fine. However when I close a tab the application crashes in pthread_join because of a semwait_signal.

originally I assumed it was a typo (I prefer to hand type code from the pages rather than download): - but the downloaded webserver-thread.m from the book site had the same problem. It looks as if the earlier statement in main {} for the if(signal(SIGPIPE, SIG_IGN) == SIG_ERR) doesn’t seem to be hit.

Does anyone have any ideas/suggestions of how to troubleshoot this problem? [This may be more useful that simply fixing as I am unused to troubleshooting in multiple thread with signals etc]

2

Ok - I think I have figured this out. (I was doing something else for the rest of the day and returned to this once that other stuff was finished).

The problem arises if you close an open safari/chrome / etc tab during the write of a long sequence of numbers. Then you get a crash because of an untrapped SIGPIPE signal.

The issue seems to be that the trap…

// block SIGPIPE so we don't croak if we try writing to a closed connetion
if(signal(SIGPIPE, SIG_IGN) == SIG_ERR) {
    fprintf(stderr, "could not ignore SIGPIPE. erroe is %d/%s\n",
    errno, strerror(errno));
    goto bailout;
}

in the main {} doesn’t properly trap the SIGPIPE signal.

Putting this in the return Numbers {} method seems to trap this OK. Crudely…

fprintf(commChannel, "<h2>The numbers from %d to %d</h2>\n", min, max);
for (i=min;  i<=max; i++) {
    if(signal(SIGPIPE, SIG_IGN) == SIG_ERR) {
        fprintf(stderr, "could not ignore SIGPIPE. erroe is %d/%s\n",
                errno, strerror(errno));
        return;
    }
    sleep(2);
    fprintf(commChannel, "%d\n", i);
    fflush(commChannel);
}
fprintf(commChannel, "<hr>Done\n");

I suspect we could probably put this higher up in the thread call - or make it a global signal handler or something to get this closer to bulletproof. Anyway at least the results make sense now and as a bonus I understand a bit more about signal trapping.

Many thanks for being a sounding board - David