Abnormal signals under Linux

We describe the names of some standard signals and the events they represent. Each signal name is a macro that represents a positive integer, but you do not attempt to speculate on the exact value represented by the macro, but instead use the name directly. This is because the value varies with different systems or different versions of the same system, but the names are standardized and uniform.
These names are defined in signal.h.
int Nsig is a defined macro that describes the number of signals that are defined. Since the value of the signal is continuously allocated from 0, the Nsig is 1 larger than the maximum signal value defined in the system.

11.2.1 Program Error Signal
The signals described below are caused by a program error. These serious errors can be detected by the computer or the operating system. In general, this signal is generated to indicate that your program has been severely damaged and there is no way to proceed with the calculation that generated the error.
Many programs need to control these signals to do some cleanup before the program exits. For example, close temporary files, clean up buffers, and so on. The program can register a function handle to complete the work, and then let the system perform the default action to end the execution of the process. Termination may be the last action of a program that produces such errors, but there are exceptions, such as some programs that are executed in an interpreted environment, which need to be returned to explain the environment itself when an error occurs.
The default action for this type of signal is to terminate the execution of the program. If you define your own processing without the final call to terminate the process, or block or ignore the signal, your program can have extremely serious consequences. Unless the signal itself is not an error, it is sent directly through the system by calling the kill function or the raise function.
When these signals end the process, a kernel dump file is generated to record the state of the program before the error exits. The filename of the kernel dump file is the core, which is written to the current directory of the current process. In a Linux system, you can also set the file name that generates the kernel dump file by using the environment variable corefile. The purpose of generating a kernel dump file is to help you afterwards use the debugger to pinpoint the cause of the error.
The names of such signals are described below:
int SIGFPE
This signal indicates that a fatal arithmetic operation error has occurred. Although the name of the signal originates from a "floating-point exception (floating-point exception)", it actually contains all the arithmetic instruction errors, including the divisor of 0 and overflow.
int Sigill
The name of this signal is derived from the "illegal instruction (illegal instrution)", which often means that your program executes commands that are simply not decoded or that you do not have permission to execute. Since the C language can only compile to produce valid legitimate instructions, the sigill signal in many cases indicates that the executable file is corrupt, or that the data is being executed as code. In the latter case, it is often because a pointer is passed as a function pointer, or the array breaks the data of the stack segment, causing the function to return an address error. Sigill can also be caused by a stack overflow, or a handle to the signal response function that the system cannot perform to pass to the system.
int SIGSEGV
This signal occurs when a program attempts to read or write memory that is allocated to it by the system, or to write memory that has read-only access. In fact, due to the limitations of the operating system detection mechanism, the detection of the program is not so timely, often only when the range is far away from the system will be detected. The name of the signal is derived from "segment Variation (segmentation violation)". This signal is often caused by references to pointers that are not initialized or null, or when referencing an array with pointers that are out of bounds due to lax checking.
int Sigbus
This signal is generated by referencing an invalid pointer. Similar to SIGSEGV, typically it is also due to incorrect initialization of pointers. The difference is that SIGSEGV refers to a valid memory address with an invalid pointer, while Sigbus references an invalid memory address. Sigbus usually occurs because pointer variables are not initialized correctly, for example, the pointer points to a 8-byte aligned variable and the address referenced is an odd number. The name of the signal is the abbreviation for "Bus error".
int SIGABRT
This signal is generated by the program call Function abort (). For the use of the function abort (), see the previous section.
int Sigiot
In a Linux system, it is another name for SIGABRT.
int SIGTRAP
The signal is generated by the computer's breakpoint instruction. The debug program uses this signal. When the program executes the command to set a breakpoint, it causes the signal to be sent, while the debugger captures the signal, obtains control, and performs the program debugging. Therefore, your program is unable to see the signal.
int SIGEMT
Simulates a self-trapping signal. It is not implemented by the system and must be caused by a software-simulated instruction. Intercept the signal and simulate the execution of the command that caused the signal in the software.
int Sigsys
The wrong system call. That is, the program makes a system call, but the calling number passed to the system is wrong and the system cannot complete the call.

11.2.2 Program Termination Signal
All of these signals are used to tell the program to end in some way. They have different names because they use a slightly different purpose, or the program wants to handle them in a slightly different way. Although these signals have the same consequences for the program, they are the end of the execution of the program, but there are reasons to deal with these signals. This is usually because the program wants to clean up before the end, for example, to record a certain state, and so on.
The default processing (currently) is to end the execution of the process.
int SIGTERM
The signal is one of the most common signals to let the program end. A process can block, control, and ignore the signal, and it is polite to ask a program to end a common method, for example, by using the shell command kill to send the signal end process by default.
int SIGINT
This name is the abbreviation for program interrupt, which sends a signal to the process when the user enters the terminating character (usually ctrl-c) from the console.
int Sigquit
This signal is similar to SIGINT, except that it is generated by the user input exit character (usually ctrl-/), the process exits, and a kernel dump is generated, as if the error signal was received. For this signal, you can think of it as a way for the user to notice a program error. Some exit cleanup is best done when processing the signal, which allows the user to view the state at that time by dumping the kernel.
int SIGKILL
The Sigkill signal is used to allow the process to terminate immediately, it cannot be controlled and ignored, is always fatal, and cannot be blocked. This signal can usually only be generated directly by a specific command, since it is not negligible, you should use it as a last resort, and first use less drastic means, such as ctrl-c or Sigterm methods. If a process does not respond to other end signals, the sigkill signal is used, which always allows the program to end. In fact, if the sigkill signal doesn't work, you should report a kernel error. When a process cannot proceed due to a reason, the system can also send the message to end the execution of the process.
int SIGHUP
The Sighup signal (hang up) reports that the user's terminal has been disconnected from the system or used as a means of operation control.

11.2.3 Alarm Clock signal
Such signals are used to indicate that the timer is active and the default behavior of the signal is to let the process end. While this default behavior is usually of little use, no other default behavior is available. Therefore, it is often necessary for the program to control the behavior of such signals with its own functions.
int SIGALRM
The signal is used by timers using the actual time or number of clocks, such as the alarm () function.
int SIGVTALRM
The function is used by a function that uses the CPU time used by the current process.
int Sigprof
This signal is used to indicate the CPU time used by the current process and the combined CPU time consumed by the system serving the current process, typically used to generate a brief summary of the code.

11.2.4 asynchronous I/O signal
This type of signal is related to asynchronous I/O operations, and you must call the Fcntl () function directly to make certain file descriptors produce that signal. The default action of this signal is to ignore the function of the signal.
int SIGIO
The Sigio signal is sent when an open file descriptor is ready for input and output. On many systems, only the terminal and the socket interface can send this signal, and ordinary files will not send this signal. On the GNU system, any file, as long as you indicate that it is open asynchronously, may send this signal.
int Sigurg
This signal is used only to indicate that the socket is used for emergency or out-of-band data, see the section behind network programming.
int Sigpoll
System V signals, similar to Sigio, are only set up for compatibility purposes.

11.2.5 Operation Control Signal
This set of signals is used to support job control, and in general, you can use the system default behavior without having to take care of these signals, unless you know exactly how to control the work of the operating system.
int SIGCHLD
When a child process is finished, the signal is sent to the parent process. The default behavior of the signal is to ignore, when the process establishes a function handle to handle the signal, and this is already a zombie process exists, then whether to produce the signal is determined by the system.
int SIGCLD
The old name of the signal sigchld.
int Sigcont
The function of this signal is to keep the process going when the process is stopped, without doing any other work. You cannot block the signal, but you can set a handler handle for the signal, which always causes the process to execute unconditionally. Most programs have no reason to control the signal, they simply continue to be interrupted operations. You can use the handle of the handler to do some of the special work you need, such as re-printing some hints if the program is suspended because it waits for input.
int SIGSTOP
The signal stops a process and it cannot be controlled, ignored, or blocked.
int SIGTSTP
This is an interactive stop signal. Unlike Sigstop, it can be controlled or ignored. This signal is generated when you enter the Susp character (ctrl-z) from the console.
int Sigttin
When a process executes in the background, it cannot read any input from the user's terminal. When a background process attempts to read from the user terminal, all processes receive a sigttin signal. The default action for this signal is to stop the process, allowing the background process that needs to be entered to read the required input information to the foreground.
int Sigttou
It is similar to Sigttin, only when the background process is writing the terminal.
When a process stops, no signal is passed to it, except for the Sigkill and Sigcont signals (obviously), all signals to it are marked as undecided (pending), and are eventually passed only when the process is re-entering the execution state. Sigkill signals always force the process to end and cannot be blocked, ignored, or controlled. You can ignore the sigcont signal, but it will always allow the stopped process to continue executing. A Sigcont signal allows all undecided stop signals to be discarded, similar to a stop signal that allows an undetermined sigcont signal to be discarded.

11.2.6 Operation Error Signal
   This set of signals is caused by a process operation error, and they do not have to be a program error, but any error that prevents the operation from completing. The default action for these signals is to abort the execution of the process.
   int Sigpipe
   If you are using a pipeline or FIFO for interprocess communication, you must have your application open the pipeline before writing to a pipeline and start reading the data. If there is no start, or the process of reading the pipeline exits unexpectedly, the write operation generates a sigpipe signal. If the sigpipe signal is blocked, controlled, or ignored, the write operation returns an error, and the error code is epipe. Further information is provided in the relevant sections later.
   int Siglost
   This signal indicates a loss of resources, and in the GNU system, it is common for any server that provides services to crash unexpectedly. It is generally not appropriate to ignore this signal because errors associated with this operation can cause the related function to return an error.
   int SIGXCPU
   CPU time limit to. This signal indicates that the limit on CPU time used by the process has been reached.
   int Sigxfsz
   This signal indicates that the process is trying to grow a file that exceeds the system's limit on file length.

11.2.7 Peripheral Signal
   This set of signals is used for a variety of purposes and generally does not affect the execution of the process.
   int SIGUSR1
   int SIGUSR2
   These two signals can be used to do whatever you want, usually for network communication. If you have a program that accepts the signal in a process, your other process can send a signal to the corresponding process. The default operation of this signal is to terminate the execution of the process.
   int Sigwinch
   sends this signal when the number of rows and columns per screen in the system terminal changes. Its default action is to ignore. If the program is a full-screen output, you need to control the signal and reinitialize the output based on the new number of rows and columns per screen.
   int Siginfo
   The signal can be sent by the console through the keyboard to all foreground process group processes. If the process that receives the signal is the lead process, it generally prints some of the current information about the system information and processes, and if it is another process, it will not do anything by default.

11.2.7 Signal Message
   The standard signal we mentioned above can be described by a system-supplied string. We use the function strsignal () and psignal () to get the related string.
   char * strsignal (int signum)
   This function returns a static string that has been assigned to describe the text information associated with the signum signal. You do not have permission to modify the returned string, and since you can override the string in another call, you must save the string backup yourself if you need to use it in a later program. This function is an extension of the GNU system, and its prototype is contained in the String.h header file.
   void psignal (int signum, const char *message)
   The function outputs a message that describes the Signum signal to the standard error output. If the message passing the function is a null pointer or an empty string, this function prints only the standard message associated with the signal. If you pass the message parameter to a function that is not empty, the system outputs the message string and then outputs the related messages. The function is declared in the signal.h file.