When does the system send the Sigkill signal?

When does the system send Sigklill

My program will sometimes receive sigkill signals randomly, GDB will prompt:

Program terminated with signal SIGKILL, killed.
The program no longer exists.
(GDB)
And I can't find any reason. When will the system send a sigkill signal? I have no other program here to send this signal ...

Reply:
There is situations under which the kernel would send SIGKILL to a
Process. Others has mentioned the Linux OOM killer; A more rarely
Seen a cpu-time resource hard limit set (such as
via the Ulimit shell-builtin) then the kernel would send the process a
SIGKILL when the limit is reached.

The system sends a SIGKILL signal in the following cases:

1, OOM killer. Out of memory is generally caused by a program memory leak that causes a lack of RAM.

2, cpu-time resource hard limit. Use ULIMIT-T to see if the system has a limit on CPU usage time. If the limit is exceeded, the sigkill signal is sent.

3, Ptrace () (I don't quite understand)
Another fairly ' standard ' case was when the process tracing another
Process using Ptrace () dies without stopping the tracing; The traced
Process is sent a SIGKILL then. Since the process is
Being actively traced with GDB, which would apparently not apply here,
But it does explain why killing GDB would kill a process that GDB is
Attached to.

Other possible situations:
-bad memory hardware (usually results in Sigsegvs, but it looks like there is cases where SIGKILL would be generated)

Memory hardware error. Usually causes SIGSEGV, and sometimes sends Sigkill.

-Network or pseudo filesystem being ripped out from under the process

(not understand)

-Hit the SysReq key

(not understand)

-Various "secure Computing" setups which restrict the operations a process can use
Because security settings restrict the use of processes.