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: Ken Thomases <email@hidden>
- Date: Wed, 25 Mar 2009 05:41:26 -0500
On Mar 25, 2009, at 5:20 AM, Påhl Melin wrote:
2009/3/25 Ken Thomases <email@hidden>:
On Mar 25, 2009, at 2:50 AM, Påhl Melin wrote:
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
...
This is exactly what I would expect. The raise() library function is
using the kill() system call to deliver the signal. The kill() system
call is misnamed. It doesn't kill processes. It just delivers signals
(which sometimes has the side effect of killing them).
For a signal that I have told the signal handler to be ignored.
Ignoring a signal doesn't prevent it from being delivered. GDB is
stopping at the point of delivery, _before_ any decision has been made
about how to handle the signal. The fact that the process will ignore
the signal is something that is _about to happen_ in the scenario you
describe. If you were to issue the "signal SIGUSR2" command in the
debugger, your program would proceed just as it would when not
debugging.
Furthermore, if you had issued the command "handle SIGUSR2 nostop
noprint pass" prior to starting your program, GDB wouldn't even have
stopped.
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.
Wrong. As I said, GDB, by default, stops on the delivery of a signal
to the process, regardless of how that signal would eventually be
handled. Just because GDB stopped doesn't mean that the signal would
not be ignored when passed to the process.
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.
Of course GDB doesn't stop the process when you don't run it with
GDB. You are fundamentally misunderstanding what's going on.
It just makes it very hard to debug the code if I cannot use single
step in GDB.
Just do what I explained with the "handle" command. As an aside, do
note, though, that single-stepping in a multi-threaded program is not
as "clean" as you may be imagining. During that single step of the
current thread, other threads may perform arbitrarily large amounts of
computation.
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”.
Yes. Program has received the signal. This is not telling you that
the program has been killed or exited or anything of the sort. It's
just telling you that something has happened that is typically an
occasion to investigate with the debugger. In your case, you don't
want to debug in this event, so you should use the "handle" command to
tell the debugger not to stop.
(gdb)
...but when I type something at the prompt it just ignores it –
nothing happens when pressing return.
This is a more fundamental problem that has nothing to do with signals.
I recall seeing a problem about that go by recently on the xcode-users
mailing list. Check the recent archives for that list. Also, further
discussion of this issue should probably be carried on there, because
it's not really relevant to this list.
Regards,
Ken
_______________________________________________
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