Lines Matching refs:program
8 executing program. Some signals report errors such as references to
14 impossible for the program to proceed as usual, and the corresponding
15 signals normally abort the program. Other kinds of signals that report
37 * Waiting for a Signal:: Suspending your program until a signal
67 A program error such as dividing by zero or issuing an address outside
71 A user request to interrupt or terminate the program. Most environments
72 are set up to let a user suspend the program by typing @kbd{C-z}, or
108 An error means that a program has done something invalid and cannot
115 the program, not just in library calls. These include division by zero
126 synchronous signal pertains to a specific action in the program, and is
165 but for most signals, the program has a choice: ignore the signal,
167 that kind of signal. The program specifies its choice using functions
175 this way will never be delivered, not even if the program subsequently
179 If a signal arrives which the program has neither handled nor ignored,
191 signal involved. If a program you run from a shell is terminated by a
194 The signals that normally represent program errors have a special
200 If you raise a ``program error'' signal by explicit request, and this
230 * Program Error Signals:: Used to report serious program errors.
232 program.
243 @cindex program error signals
245 The following signals are generated when a serious program error is
247 all of these signals are indications that your program is seriously
251 Some programs handle program error signals in order to tidy up before
253 input should handle program error signals in order to turn echoing back
255 signal that happened and then reraising it; this will cause the program
259 Termination is the sensible ultimate outcome from a program error in
262 program incurs an error. These programs have handlers which use
267 for them that return normally, your program will probably break horribly
272 When one of these program error signals terminates a process, it also
286 If a program stores integer data in a location which is then used in a
315 Integer overflow (impossible in a C program unless you enable overflow
353 usually means your program is trying to execute garbage or a privileged
371 This signal is generated when a program tries to read or write outside
373 read. (Actually, the signals only occur when the program goes far
403 This signal indicates an error detected by the program itself and
416 trap instructions. This signal is used by debuggers. Your program will
437 @cindex program termination signals
443 The reason for handling these signals is usually so your program can
448 this will cause the program to terminate with that signal, as if it had
457 The @code{SIGTERM} signal is a generic signal used to cause program
459 handled, and ignored. It is the normal way to politely ask a program to
469 The @code{SIGINT} (``program interrupt'') signal is sent when the user
482 just like a program error signal. You can think of this as a
483 program error condition ``detected'' by the user.
490 For example, if the program creates temporary files, it should handle
498 The @code{SIGKILL} signal is used to cause immediate program termination.
512 unusual conditions where the program cannot possibly continue to run
539 The default behavior for these signals is to cause program termination.
647 a handler for @code{SIGCONT} to make a program do something special when
664 Your program should handle this signal if you have a special need to
711 program that will notice it stop and allow the user to continue it.
729 operation done by the program. They do not necessarily indicate a
730 programming error in the program, but an error that prevents an
758 On @gnuhurdsystems{}, @code{SIGLOST} is generated when any server program
780 will not affect your program unless it explicitly uses them for something.
788 communication, if you write a signal handler for them in the program
803 If a program does full-screen display, it should handle @code{SIGWINCH}.
890 of the program.
901 storage whose lifetime is the whole lifetime of the program.
985 Your program generally should not ignore signals that represent serious
988 ignore program error signals like @code{SIGSEGV}, but ignoring the error
989 won't enable the program to continue executing meaningfully. Ignoring
994 the program, the thing to do is to block them, not ignore them.
998 Supply the address of a handler function in your program, to specify
1074 We do not handle @code{SIGQUIT} or the program error signals in this
1191 functions within a single program, but you have to be careful because
1202 save and restore a handler if your program uses @code{sigaction} at all.
1215 consistently within a single program.
1265 The program just loads the @code{new_action} structure with the desired
1359 makes sense; the handler functions from the old program are specific to
1360 that program, and aren't even present in the address space of the new
1361 program image.) Of course, the new program can establish its own
1364 When a program is run by a shell, the shell normally sets the initial
1397 rest of the program. Instead of directly invoking the function, you use
1410 You can have the handler function terminate the program or transfer
1417 point in the program, unpredictably. If two signals arrive during a
1424 * Termination in Handler:: How handler functions terminate a program.
1443 flag that tells the program to exit at a convenient time.
1445 It is not safe to return normally from the handler for a program error
1446 signal, because the behavior of the program when the handler function
1447 returns is not defined after a program error. @xref{Program Error
1452 periodically by the program during normal operation. Its data type
1456 Here is a simple example of such a program. It executes the body of
1468 Handler functions that terminate the program are typically used to cause
1469 orderly cleanup or recovery from program error signals and interactive
1520 program that was running will not continue. If this part of the program
1522 structure will remain inconsistent. Since the program does not
1526 for the parts of the program that update important data structures.
1616 want your program to work properly on System V Unix. On this system,
1645 child processes that generate them. It assumes that the program keeps track
1668 since some time in the past---whenever the program last cleared it to
1719 /* @r{The program should check this flag from time to time}
1757 until the program has taken notice. @xref{Atomic Usage}, for more
1763 changed outside the handler. Instead of clearing the count, the program
1766 the program can check independently, each part checking whether there
1794 program checks regularly, and leave all serious work to the program.
1809 If your handler needs to access any global variables from your program,
1833 @code{gethostbyname}, or even after one (while the program is still
1834 using the value), it will clobber the value that the program asked for.
1836 However, if the program does not use @code{gethostbyname} or any other
1852 program was in the middle of an @code{fprintf} call using the same
1854 and the program's data could be corrupted, because both calls operate on
1858 possibly be used by the program at a time when signals can arrive, then
1859 you are safe. It is no problem if the program uses some other stream.
1872 the objects to be freed, and have the program check from time to time
1898 errors from system calls at the point the program is interrupted to run
1935 * Non-atomic Example:: A program illustrating interrupted access.
1978 This program fills @code{memory} with zeros, ones, zeros, ones,
1981 safe in this program because it is certainly not being called outside
1984 Clearly, this program can print a pair of zeros or a pair of ones. But
2026 tested and cleared by the main program from time to time, is always safe
2125 interrupt, your program can explicitly send signals to itself or to
2168 program types the SUSP character (usually @kbd{C-z}; @pxref{Special
2206 /* @r{Enable both handlers during program initialization.} */
2349 is when you run a setuid program in a child process; if the program
2351 permission to send a signal. The @code{su} program does this.
2400 deliver it later. Generally, a program does not block signals
2439 arrive in that part of the program, they are delivered later, after you
2443 handler and the rest of the program. If the type of the data is not
2445 handler could run when the rest of the program has only half finished
2448 To make the program reliable, you can prevent the signal handler from
2449 running while the rest of the program is examining or modifying that
2451 program that touch the data.
2458 the flag, but before the consequent action: then the program will
2496 well. (In addition, it's not wise to put into your program an
2614 can't predict what its contents are when your program starts running.)
2636 Remember, too, that blocking program error signals such as @code{SIGFPE}
2637 leads to undesirable results for signals generated by an actual program
2639 This is because your program may be too broken to be able to continue
2649 your main program checks this flag from time to time and then resets it.
2807 another @code{SIGINT} signal arrives, your program will probably only
2885 handler would merely set @code{defer_signal}, but the program having
2909 If your program is driven by external events, or uses signals for
2939 The @code{pause} function suspends program execution until a signal
2945 ``successful'' behavior would be to suspend the program forever), so the
2958 If the signal causes program termination, @code{pause} doesn't return
2965 until the program ends. To avoid this calls to @code{pause} should be
2976 can make a program hang mysteriously.
2978 It is safe to use @code{pause} if the real work of your program is done
2979 by the signal handlers themselves, and the ``main program'' does nothing
2982 that the main loop of the program can call @code{pause} again.
3048 words, the program is effectively suspended until one of the signals that
3091 necessary at all, since the program is apparently only waiting for one
3124 not require your program to know which direction the stack grows, which
3153 sufficient. But if you know how much stack space your program's signal