Avoiding Hard Reboots
Hard reboots are almost never necessary. If you are ever in a situation where you think you might need to do a hard reboot, you should try these alternatives first, in this order:
Press Ctrl+Alt+F1. Then press Ctrl+Alt+Delete. This will usually cleanly shut down and reboot.
If that fails, you can do something that is nearly as powerful as a hard reboot, but which decreases the risk of data loss and other possible negative outcomes of hard rebooting. Hold down Alt and SysRq and, in order, press R E I S U B. (Hold down Alt and SysRq the whole time, but release each letter key before pressing the next one.) See this page for a simple explanation of what that does, and this Wikipedia article for more detailed information.
However, in the situation you have encountered and described in your question, it is very probably not necessary to reboot at all. There is a technique that will probably work to terminate
gedit but leave everything else intact and fully functioning. You can even report the bug, though since it is not actually a crash, it won't be with a .crash file.
Recovering Without Rebooting
Since switching workspaces is possible, the system has not locked up completely. When this happens, you should be able to regain complete control of your system by doing the following:
Press Ctrl+Alt+F1 to switch from the GUI to a virtual console.
Log in with your username and password. You won't see anything appear on the screen as you enter your password. That's OK.
Now that you have a shell prompt (like in the Terminal GUI application), terminate all
gedit processes with
killall gedit. Please note that you will lose any unsaved work in any
killall gedit again to see if it worked the first time. If it says
gedit: no process found that's good--it means you successfully terminated
gedit. If it doesn't say that, then
gedit is nonresponsive to SIGTERM (the "nice" way of asking a process to terminate). In this case, terminate it with SIGKILL by running
killall -KILL gedit. Occasionally a process is in uninterruptible sleep, which means that it's waiting on a kernel I/O operation, and cannot even be terminated this way. To check for that, run
killall -KILL gedit again.
Press Ctrl+Alt+F7 to switch back to the GUI, which should now be fully functional.
Assuming the GUI is fully functional, the problem lies in the interaction between
gedit and some GUI component--it could be X11 itself, or it could be your window manager (which might be
openbox, or something else, depending on what graphical interface you use). This might be due to a bug in gedit, or in your window manager (or X11). Before reporting the bug, it would be best for you to investigate this. Sean Davis's advice is good. You should find out what window manager you use. This question can help you with that. In recent versions of Ubuntu, 3D Unity uses
compiz and Unity 2D uses
metacity. You can use the
ps command and
grep to see if a process is running, if you know its name. For example, you can use
ps x | grep compiz to see if you're running
ps x | grep metacity to see if you're running metacity. As Sean Davis says, if you're running Unity, try Unity 2D (i.e., click the gear icon on the login screen and select Ubuntu 2D) and see if the problem still occurs.
Initiating the Bug Reporting Process
Once you've gathered this information, go ahead and report the bug. A crash is when a program terminates abnormally. This bug is not a crash, so there will be no .crash file and Apport will not be able to run automatically to gather data. But you can still use Apport to collect some relevant data for reporting the bug. There are two reasonable ways to do this.
One option is to run
ubuntu-bug, passing a package name as an argument. This will gather data about the way that package is installed and configured on your system and attach it to your bug report. You should specify whatever package you think is most likely causing the problem. If the problem occurs in 3D Unity (session type "Ubuntu") but not in Unity 2D (session type "Ubuntu 2D") then it's probably in
compiz so run
ubuntu-bug compiz. (Similarly, if the problem occurs only with Unity 2D, you could run
ubuntu-bug metacity.) Otherwise, go ahead and report it against
gedit itself with
ubuntu-bug compiz includes a lot of information about
ubuntu-bug gedit includes less information about
gedit. So if you think the bug is in
gedit, and you're willing to go the extra mile, you may want to invoke Apport while
gedit is actually running, to include information about the running
gedit process. Since your GUI doesn't work when the bug is happening, you'd have to do this from the virtual console, between steps 2 and 3 above. Here's how:
Reproduce the bug by dragging a tab from one
gedit window to another.
Perform steps 1 and 2 in the above instructions.
Determine the process ID of the running
gedit process by running the command
pidof gedit. This will give you a number, the PID of the running
script and press enter. This records all the text on the console.
apport-cli $PID, but replace
$PID with the process ID of the running edit process as determined in step 3.
Provide any information that Apport requests on the command-line. You should get a URL. It will be long and random-looking, and thus very hard to remember. That's why you ran
script to record everything.
exit (to quit
gedit and switch back to the GUI by performing steps 3, 4, and 5 in the above instructions.
script created a file called
typescript, located right in your home directory. Find this file and open it with
gedit or another text editor. Copy the URL from it and open it in your web browser.
You will be given the opportunity to write a bug report in your web browser.
Writing and Submitting Your Bug Report
However you report the bug, you'll be writing a report in your web browser and submitting it. The report should be as detailed as possible. It should describe how to produce the bug, the package version for
gedit and whatever package provides your window manager (e.g.,
metacity), and an explanation of what conditions are required for the bug to occur (for example, does it occur in all interfaces, or only Unity 3D, or something else).
Before submitting your bug report, you should make sure to read this page carefully if you have not done so already.
After you submit your bug report, it is advisable to add any additional packages you think are likely to be affected. Usually, it is clear what package is affected by a bug, but in this case, it is not completely clear. Even if the problem happens with
compiz and not
metacity, there could still be a problem in
gedit itself contributing to the bug.
If you reported the bug against
metacity or some other window manager), you can add the
gedit package as affected. If you reported it against the
gedit package because you were able to produce the bug with at least two different window managers, then you should not add any window manager package as affected (unless there is some window manager with which you have found that the bug does not occur). Instead, you can add the
To add another package besides the one against which you initially reported the bug, go to the bug page on Launchpad (if you're not already there) and click
Also affects distribution. Specify
Ubuntu as the distribution (since you're saying it affects another package in Ubuntu). Then specify the name of the additional package you think may be affected, as the package name.
With more than one package listed for the bug, it's likely (though not certain) that all but one will be considered wrong and marked Invalid. That's OK. But reporting the bug against all the packages that seem likely to be affected, you're giving bug triagers and developers for those packages the opportunity to review your bug and determine if they think it's affecting their package. (But I emphasize that usually you should not do this, because usually it's possible to figure out, perhaps with community help, which package a bug is in before reporting it.)