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 gedit
windows/tabs.
Run 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 compiz
, metacity
, 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 compiz
or 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 gedit
.
Running ubuntu-bug compiz
includes a lot of information about compiz
, but 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 gedit
process.
Type script
and press enter. This records all the text on the console.
Run 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.
Run exit
(to quit script
).
Kill 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., compiz
or 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 compiz
(or 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 xorg
package.
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.)