What needs to be understood here is that the name of the core file may be different in different implementations. For example, in FreeBSD 8.0, the core filename is cmdname.core, where cmdname is the name of the command executed by the process that received the signal; in Mac OS 10.6.8, the core filename is core.pid, where pid is the received signal The ID of the process of the signal. These systems allow the core filename to be configured via the sysctl parameter, eg Linux 3.2.0 via /proc/sys/kernel/core_pattern. Most implementations include a core file entry in the working directory of the corresponding process, but Mac OS X places all core files in the /cores directory.
In addition, the core file is not generated under the following conditions:
(1) The process is set with the user ID, and the current user is not the owner of the program file.
(2) The process is to set the group ID, and the current user is not the group owner of the program file.
(3) The user does not have permission to write to the current working directory.
(4) The file already exists, and the user does not have write permission to the file (the permission of the core file is usually user read/write).
(5) The file is too large.
When the process catches the signal and handles it, it temporarily interrupts the normal sequence of instructions it is executing, executes the instructions in the signal handler instead, and resumes after returning from the signal handler (if exit or longjmp is not called) implement. But in a signal handler, you can't tell where the process is executing when the signal is caught. If the process is executing malloc, it can cause damage to the process, because malloc usually maintains a linked list for the memory it allocates, and the process may be changing this linked list when the signal handler is inserted. For another example, if a process is executing a function such as getpwnam that stores its result in a static storage unit, inserting a signal handler, and calling such a function, the information returned to the normal caller may be overwritten.
The following table lists the functions that the Single UNIX Specification states that are guaranteed to be call-safe in a signal handler, are reentrant, and are said to be asynchronous signal-safe. Additionally, during signal handling operations, they block any signaling that would cause inconsistencies.
Most not in this table are not reentrant because (a) they are known to use static data structures; (b) they call malloc or free; (c) they are standard I/O functions (the standard I/O library Many implementations of using global static data structures in a non-reentrant way). However, even if the signal handler calls the functions in the above table, since there is only one errno variable per thread, the signal handler may modify its previous value. Therefore, you should save errno before calling the function in the above figure in the signal handler, and restore errno after the call.
Note that functions such as longjmp and siglongjmp are not included in the diagram above because the main routine may generate a signal while it is updating a data structure in a non-reentrant manner. If instead of returning from the signal handler, siglongjmp is called, the data structure may be partially updated. If you want to update the entire data structure while catching some signals whose handlers cause siglongjmp to be executed, block such signals while updating.