Re: signal(SIGUSR2, SIG_IGN) not respected by Xcode/GDB?
Re: signal(SIGUSR2, SIG_IGN) not respected by Xcode/GDB?
- Subject: Re: signal(SIGUSR2, SIG_IGN) not respected by Xcode/GDB?
- From: Påhl Melin <email@hidden>
- Date: Wed, 25 Mar 2009 11:20:17 +0100
2009/3/25 Ken Thomases <email@hidden>:
> On Mar 25, 2009, at 2:50 AM, Påhl Melin wrote:
>
>> I have a C++ singleton class where you call methods to execute
>> commands that are actually performed by a background thread. When a
>> command is "requested" it is put in a queue and I use raise(SIGUSR2)
>> to wake-up the background thread. The reason I use signals to wake-up
>> the background thread is that it communicates with other processed
>> using Unix Domain Sockets and is listening to socket activity using a
>> kqueue() and can also conveniently be used to listen to raised
>> signals.
>
> Have you considered using a pipe instead? Just send a single byte (contents
> unimportant) on the pipe to wake the thread. The thread should drain the
> pipe whenever it wakes up, and then check whatever state information
> necessary to do its work. Etc.
I'm not completely satisfied using signals (especially since they are
not dynamically allocated and I may want to use more in the future)
but signals was the lowest level alternative I could think about. This
code will be used _very_ frequently and I want to use the lowest
possible level, mainly for performance reasons but also for ease of
setup. And signals seems like a reasonable alternative considering
this.
>> When the singleton is constructed the first time I use signal(SIGUSR2,
>> SIG_IGN) to ignore the default signal handler to kill the process. And
>> this works great when running the program both in Xcode and in a
>> terminal window BUT when I put a breakpoint in the program and GDB is
>> run, the program crashes when raise(SIGUSR2) is executed and kills the
>> process as if the signal(SIGUSR2, SIG_IGN) had not been called (which
>> I know has been called).
>
> Are you sure the process is dying? By design, GDB stops (but doesn't kill)
> the process whenever it receives a signal. It allows you to investigate the
> state of the process if the signal was unexpected.
I have only used GDB from within Xcode and it doesn't kill the process
but according to the stack trace I get:
0 __kill
1 kill$UNIX2003
2 raise
3 SendCommandToService
...
For a signal that I have told the signal handler to be ignored. The
strange thing is that it works great as long as I don't invoke a
breakpoint that starts GDB. So something about GDB makes the default
signal handler being used despite having told it to be ignored. I can
even put the line signal(SIGUSR2, SIG_IGN); just before the
raise(SIGUSR2); line and it will still trap the signal – something it
doesn't do if I run without GDB.
It just makes it very hard to debug the code if I cannot use single
step in GDB.
> You can control this behavior using GDB's "handle" command. Try typing
> "help handle" or "info handle" at GDB's prompt.
>
> You can deliver the signal to the process using GDB's "signal" command. You
> can also continue the process without delivering the signal using
> "continue".
When GDB stops it outputs:
run
[Switching to process 59985 local thread 0x2d03]
Running…
Program received signal: “SIGUSR2”.
(gdb)
...but when I type something at the prompt it just ignores it –
nothing happens when pressing return.
/ Påhl
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden