\begin{description}
\item[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.
- \item[Cinelerra crash:] This is covered in \ref{cha:Crash Dumps for Analysis} Crash Dumps for Analysis, chapter 18. 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.
+ \item[Cinelerra crash:] This is covered in \ref{cha:crash_dumps_analysis} Crash Dumps for Analysis, chapter 18. 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.
\item[X Server crash:] Keyboard does not respond, screen is frozen, caps lock may operate LED light. Sometimes using \texttt{ctrl-alt-F1} $\dots$ \texttt{ctrl-alt-F7} (etc.) will allow you to regain control of a VT console. You can use this to login and check logs: eg. \textit{/var/log/Xorg.0.log}, \textit{dmesg}, \textit{journalctl} $\dots$ 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, $\dots$ or whatever.
\item[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 \textit{guest} kernel, but this also requires a lot of setup, and affects which kernel is currently under test. The kdb route is preferable.
\item[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 \texttt{/etc/X11/xorg.conf} X config contains special setup as shown below:
projects / goodguy / cin-manual-latex.git / blobdiff