General Crash Handling Tips

This section is a handy guide for describing various kinds of software computer system failures. Only some of these various lockups or crashes can be dealt with. Hopefully, it will help to have some hints to know what kind of failure it is, or to save your work or to avoid future problems. For most of this, your user name must be root, although you can certainly try to see if it works for you when not root.

System lockups:

When the system locks up, it is usually a system problem. Normally an application program cannot lock up the system. It is a major goal of system design to prevent an application (app) from failing a system interface. This does not mean an app can not cause a system lockup, but it is unusual.

CINELERRA-GG crash:

This is covered in Crash Dumps for Analysis. Just a reminder that for best results you should be root and by providing a crash dump and as much other information as possible, you will be helping the developer to analyze the problem and fix it so that it can be avoided in the future.

X Server crash:

Keyboard does not respond, screen is frozen, caps lock may operate LED light. Sometimes using Ctrl-Alt-F1 ... Ctrl-Alt-F7 (etc.) will allow you to regain control of a VT console. You can use this to login and check logs: eg. /var/log/Xorg.0.log, dmesg, journalctl ... etc. If you have another computer, make sure a terminal server is configured (for example: rsh, ssh, or telnet), then remote login via this other computer and check the logs. Most important is to immediately note the current software state, and the very last thing that preceded the crash, i.e. last button click, last keystroke, ... or whatever.

Kernel crash:

The machine goes completely dead. The keyboard caps lock LED will probably be flashing. Most likely the only way to see anything after the kernel crashes is to use a serial port console log and usually kdb, the kernel debugger, and special cabling. This requires a lot of setup, and is normally reserved for experts. Login from another computer will not work. Pinging the ip address will not respond since the network stack is part of the kernel. There are some virtual machine setups that will let you debug a guest kernel, but this also requires a lot of setup, and affects which kernel is currently under test. The kdb route is preferable.

Keyboard grabs, Server grabs, and Deadlocks:

A grab is an X-server state where all events are forced to just one window event stream. This forces the user to respond to the dialog. Things seems to be working, but no keypresses do anything useful. The system clock and other programs will still be working. The network will work for remote logins. Grabs can be canceled if the /etc/X11/xorg.conf X config contains special setup as shown below:

Section "ServerFlags"
	Option      "HandleSpecialKeys" "Always"
	Option      "AllowDeactivateGrabs" "True"
	Option      "AllowClosedownGrabs" "True"
EndSection

Section "InputDevice"
	Identifier  "Keyboard"
	Driver      "evdev"
	...
	Option "XkbOptions" "terminate:ctrl_alt_bksp"
	Option "XkbOptions" "grab:break_actions"
EndSection

or to $HOME/.xinitrc, add:

#  xkb terminate/grab actions disabled in xorg.conf, use:	
setxkbmap -option "grab:break_actions"
setxkbmap -option "terminate:ctrl_alt_bksp"
ctrl-alt-bksp = terminate the X-server, may restart automatically

Modal forms (always on top, and usually ptr/kbd grab) dialog boxes can lock a system by putting a form over another form holding a grab. This means the form that needs input may never get any because you can not get to it, and the result is a deadlock. Usually you will have to restart X (Ctrl-Alt-Bksp).

Window Manager issues:

The desktop window manager can intercept and modify all kinds of user input. Mostly, this is a good thing, but can be a nuisance. If user keypresses can be programmed to trigger actions, then they may be useful to send KILL or INTR to an app that seems to be holding X's attention. For example:

	killall -INTR cinelerra,
	killall -9 cinelerra,	
	killall X,
	# but you must run as root to be able do this

The ALT and META keys may be intercepted by the window manager, and this can cause unexpected interface operations.