Perhaps a list of possible ways a program can hang itself and/or the system would help:

• CPU overload -- but usually the OS gives other things time slices too, unless you have grabbed real time priority
• memory overload -- swap can make this better or worse (usually worse); mitigation is to tune your OOM killer or restrict memory use with ulimits or cgroups
• Disk overload -- if your app uses so much disk I/O that other applications are stuck waiting; this can be combined with a memory issue to cause thrashing, which doesn't truely lock up your computer but certainly makes it feel that way and may not be practically recoverable
• Input device lockup -- if your application grabs keyboard and mouse and then hangs, there may not be a way to recover without an out of band input (like ssh from another terminal or kernel SAK. Kernel SAK is usually disabled by default for security reasons, and its actions are typically overkill anyway, so this is the worst solution.)

I'm sure there's others I've missed.

If your application itself is locking up, it may be possible to add a watchdog within the application to either try to clean things up, or maybe in debug mode, abort completely.

Another mitigation for infinite loops within the application is to design to detect them or allow them. To detect them, in a code section that it is possible to have a stuck loop, leave a hook for a watch dog timer or countdown timer and abort the loop when it triggers. To allow them, either treat the loop as an event, and for the next iteration, have it add itself back to the event queue; or add yields within the possible infinite loop to allow it to be postponed or aborted.

Perhaps a list of possible ways a program can hang itself and/or the system would help:

• CPU overload -- but usually the OS gives other things time slices too, unless you have grabbed real time priority
• memory overload -- swap can make this better or worse (usually worse); mitigation is to tune your OOM killer or restrict memory use with ulimits or cgroups
• Disk overload -- if your app uses so much disk I/O that other applications are stuck waiting; this can be combined with a memory issue to cause thrashing, which doesn't truely lock up your computer but certainly makes it feel that way and may not be practically recoverable
• Input device lockup -- if your application grabs keyboard and mouse and then hangs, there may not be a way to recover without an out of band input (like ssh from another terminal or kernel SAK. Kernel SAK is usually disabled by default for security reasons, and its actions are typically overkill anyway, so this is the worst solution.)
• GPU overload or crash -- it is possible to overload the gpu so that it becomes slow or seemingly unresponsive. Sometimes it is possible to trigger bugs in the gpu driver that causes a display lockup or crash. This may or may not lock up the rest of the system; if it does, there is no recovery except to reset. If it doesn't, the only recovery may be to ssh in and reboot, and even then sometimes a power cycle is required after shutdown.

I'm sure there's others I've missed.

If your application itself is locking up, it may be possible to add a watchdog within the application to either try to clean things up, or maybe in debug mode, abort completely.

Another mitigation for infinite loops within the application is to design to detect them or allow them. To detect them, in a code section that it is possible to have a stuck loop, leave a hook for a watch dog timer or countdown timer and abort the loop when it triggers. To allow them, either treat the loop as an event, and for the next iteration, have it add itself back to the event queue; or add yields within the possible infinite loop to allow it to be postponed or aborted.

Perhaps a list of possible ways a program can hang itself and/or the system would help:

• CPU overload -- but usually the OS gives other things time slices too, unless you have grabbed real time priority
• memory overload -- swap can make this better or worse (usually worse); mitigation is to tune your OOM killer or restrict memory use with ulimits or cgroups
• Disk overload -- if your app uses so much disk I/O that other applications are stuck waiting; this can be combined with a memory issue to cause thrashing, which doesn't truely lock up your computer but certainly makes it feel that way and may not be practically recoverable
• Input device lockup -- if your application grabs keyboard and mouse and then hangs, there may not be a way to recover without an out of band input (like ssh from another terminal or kernel SAK)

I'm sure there's others I've missed.

If your application itself is locking up, it may be possible to add a watchdog within the application to either try to clean things up, or maybe in debug mode, abort completely.

Another mitigation for infinite loops within the application is to design to detect them or allow them. To detect them, in a code section that it is possible to have a stuck loop, leave a hook for a watch dog timer or countdown timer and abort the loop when it triggers. To allow them, either treat the loop as an event, and for the next iteration, have it add itself back to the event queue; or add yields within the possible infinite loop to allow it to be backgrounded.

Perhaps a list of possible ways a program can hang itself and/or the system would help:

• CPU overload -- but usually the OS gives other things time slices too, unless you have grabbed real time priority
• memory overload -- swap can make this better or worse (usually worse); mitigation is to tune your OOM killer or restrict memory use with ulimits or cgroups
• Disk overload -- if your app uses so much disk I/O that other applications are stuck waiting; this can be combined with a memory issue to cause thrashing, which doesn't truely lock up your computer but certainly makes it feel that way and may not be practically recoverable
• Input device lockup -- if your application grabs keyboard and mouse and then hangs, there may not be a way to recover without an out of band input (like ssh from another terminal or kernel SAK. Kernel SAK is usually disabled by default for security reasons, and its actions are typically overkill anyway, so this is the worst solution.)

I'm sure there's others I've missed.

If your application itself is locking up, it may be possible to add a watchdog within the application to either try to clean things up, or maybe in debug mode, abort completely.

Another mitigation for infinite loops within the application is to design to detect them or allow them. To detect them, in a code section that it is possible to have a stuck loop, leave a hook for a watch dog timer or countdown timer and abort the loop when it triggers. To allow them, either treat the loop as an event, and for the next iteration, have it add itself back to the event queue; or add yields within the possible infinite loop to allow it to be postponed or aborted.