3

I'm running 12.04 on a Dell desktop (that originally came with just 10.04 installed), and when I try to drag a Gedit tab from one window to another, the entire system freezes, solvable only with a hard reboot. I'm not sure how I can get a .crash file from this and will need additional assistance because:

  1. I'm in the middle of finals and don't have a chance right now to look into it
  2. the only thing I can do once the crash happens is switch workspaces and open a terminal with keyboard commands (though in the terminal alphanumeric characters are all that work - the space bar does nothing and neither does hitting enter.

Has anyone else seen this problem? A quick search returned nothing.

2
  • The only time I have seen this happen was because of the graphics card. I don't want to rule it out so what kind do you have? If you used any other application and did the same process, do you get the same issue? Can you use gedit if you didn't move it (can you write, save, etc...)?
    – ruffEdgz
    May 9, 2012 at 15:45
  • I had seen the same thing when I dragged a tab from one gedit window to another gedit window in the same workspace. I don't know why I did it but I did. This was on 11.10 (Unity 3D) running on a Dell Inspiron 1545 laptop. There was no problem if I dragged a tab to a clear space on the desktop.
    – user25656
    May 9, 2012 at 16:18

2 Answers 2

4

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:

  1. Press Ctrl+Alt+F1. Then press Ctrl+Alt+Delete. This will usually cleanly shut down and reboot.

  2. 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:

  1. Press Ctrl+Alt+F1 to switch from the GUI to a virtual console.

  2. Log in with your username and password. You won't see anything appear on the screen as you enter your password. That's OK.

  3. 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.

  4. 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.

  5. 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:

  1. Reproduce the bug by dragging a tab from one gedit window to another.

  2. Perform steps 1 and 2 in the above instructions.

  3. 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.

  4. Type script and press enter. This records all the text on the console.

  5. Run apport-cli $PID, but replace $PID with the process ID of the running edit process as determined in step 3.

  6. 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.

  7. Run exit (to quit script).

  8. Kill gedit and switch back to the GUI by performing steps 3, 4, and 5 in the above instructions.

  9. 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.

  10. 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.)

0

What environment are you using? It might be related to the compositor if you are using Unity or Gnome Shell. Try using Unity 2D and see if the same problem happens.

Not the answer you're looking for? Browse other questions tagged .