(ddd.info)Signals

---

Next: Killing the Program Prev: Threads Up: Running

---

Enter node , (file) or (file)node

6.10 Handling Signals
=====================

A signal is an asynchronous event that can happen in a program.  The
operating system defines the possible kinds of signals, and gives each
kind a name and a number.  For example, in UNIX, `SIGINT' is the signal
a program gets when you type an interrupt; `SIGSEGV' is the signal a
program gets from referencing a place in memory far away from all the
areas in use; `SIGALRM' occurs when the alarm clock timer goes off
(which happens only if your program has requested an alarm).

   Some signals, including `SIGALRM', are a normal part of the
functioning of your program.  Others, such as `SIGSEGV', indicate
errors; these signals are _fatal_ (kill your program immediately) if
the program has not specified in advance some other way to handle the
signal.  `SIGINT' does not indicate an error in your program, but it is
normally fatal so it can carry out the purpose of the interrupt: to
kill the program.

   GDB has the ability to detect any occurrence of a signal in your
program.  You can tell GDB in advance what to do for each kind of
signal.

   Normally, DDD is set up to ignore non-erroneous signals like
`SIGALRM' (so as not to interfere with their role in the functioning of
your program) but to stop your program immediately whenever an error
signal happens.  In DDD, you can view and edit these settings via
`Status => Signals'.

   `Status => Signals' pops up a panel showing all the kinds of signals
and how GDB has been told to handle each one.  The settings available
for each signal are:

`Stop'
     If set, GDB should stop your program when this signal happens.
     This also implies `Print' being set.

`Print'
     If set, GDB should print a message when this signal happens.

     If unset, GDB should not mention the occurrence of the signal at
     all.  This also implies `Stop' being unset.

`Pass'
     If set, GDB should allow your program to see this signal; your
     program can handle the signal, or else it may terminate if the
     signal is fatal and not handled.

     If unset, GDB should not allow your program to see this signal.

   The entry `All Signals' is special.  Changing a setting here affects
_all signals at once_--except those used by the debugger, typically
`SIGTRAP' and `SIGINT'.

   To undo any changes, use `Edit => Undo'.  The `Reset' button
restores the saved settings.

   When a signal stops your program, the signal is not visible until you
continue.  Your program sees the signal then, if `Pass' is in effect
for the signal in question _at that time_.  In other words, after GDB
reports a signal, you can change the `Pass' setting in `Status =>
Signals' to control whether your program sees that signal when you
continue.

   You can also cause your program to see a signal it normally would not
see, or to give it any signal at any time.  The `Send' button will
resume execution where your program stopped, but immediately give it the
signal shown.

   On the other hand, you can also prevent your program from seeing a
signal.  For example, if your program stopped due to some sort of memory
reference error, you might store correct values into the erroneous
variables and continue, hoping to see more execution; but your program
would probably terminate immediately as a result of the fatal signal
once it saw the signal.  To prevent this, you can resume execution using
`Commands => Continue Without Signal'.

   Signal settings are not saved across DDD invocations, since changed
signal settings are normally useful within specific projects only.
Instead, signal settings are saved with the current session, using
`File => Save Session As'.