On Jul 7, 2010, at 11:08 PM, Bill Bumgarner wrote:
> On Jul 7, 2010, at 9:59 AM, Matt DeFoor wrote:
>> Is the app performing socket IO? If so, simply setting up a handler
>> for SIGPIPE is sometimes not good enough. You may have to test if you
>> can write to the socket:
> And... sometimes it really is the debugger. The debugger is often configured to handle signals by breaking, even when handling of the signal is something you might expect.
Alex's original complaint was that his SIGPIPE handler wasn't getting called. The debugger shouldn't affect whether the handler is getting called or not (unless of course you've set it to suppress the signal with the "handle" command.) By default, gdb will stop on SIGPIPE but also pass it on, which should trigger the handler:
(gdb) handle SIGPIPE
Signal Stop Print Pass to program Description
SIGPIPE Yes Yes Yes Broken pipe
If the breaking annoys you, you can do:
(gdb) handle SIGPIPE nostop
If you have a case where a signal doesn't get delivered when run under the debugger, but does when not run under the debugger, that's a bug and please file it. But I think Alex's problem is that the signal wasn't getting tripped at all.
> However, in general and in the large, you should never ever write application code that tries to handle signals unless you absolutely positively have to. In unix signal handlers, you are pretty much not allowed to do anything interesting. Memory allocations and, thus, Objective-C messaging isn't allowed, for example.
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> This email sent to email@hidden
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden