我在戴尔台式机上运行 12.04（最初只安装了 10.04），当我尝试将 Gedit 选项卡从一个窗口拖到另一个窗口时，整个系统冻结，只能通过硬重启来解决。我不确定如何从中获取 .crash 文件，需要额外的帮助，因为：
- 我正在期末考试，现在没有机会研究它
- 崩溃发生后我唯一能做的就是切换工作区并用键盘命令打开终端（尽管在终端中只有字母数字字符起作用 - 空格键不起作用，按回车键也不起作用）。
还有人见过这个问题吗？快速搜索没有结果。
答案1
避免硬重启
几乎从来都不需要硬重启。如果您认为可能需要硬重启，则应首先按以下顺序尝试以下替代方案：
按Ctrl+ Alt+ F1。然后按Ctrl+ Alt+ Delete。这通常会干净地关闭并重新启动。
如果失败了，你可以做一些几乎和硬重启一样强大的事情，但可以降低数据丢失的风险以及硬重启可能带来的其他负面后果。按住Alt和SysRq，然后按顺序按下R E I S U B。（一直按住Alt和SysRq，但在按下下一个字母键之前先松开每个字母键。）参见这一页简单解释一下它的作用，以及这篇维基百科文章了解更多详细信息。
但是，就你所遇到并在问题中描述的情况而言，很可能根本不需要重新启动。有一种技术可能可以终止程序gedit，但其他一切都完好无损，功能齐全。您甚至可以报告错误，尽管由于它实际上不是崩溃，因此不会出现 .crash 文件。
无需重启即可恢复
由于可以切换工作区，因此系统尚未完全锁定。发生这种情况时，您应该能够通过执行以下操作重新获得对系统的完全控制：
按Ctrl+ Alt+F1从 GUI 切换到虚拟控制台。
使用您的用户名和密码登录。输入密码时，屏幕上不会出现任何内容。没关系。
现在您有了 shell 提示符（就像在终端 GUI 应用程序中一样），请
gedit使用 终止所有进程。请注意，您将丢失所有窗口/选项卡killall gedit中未保存的工作。gedit再次运行
killall gedit以查看第一次是否成功。如果它说gedit: no process found没问题——这意味着您已成功终止gedit。如果它没有说，则gedit对 SIGTERM 没有响应（要求进程终止的“好”方式）。在这种情况下，通过运行 用 SIGKILL 终止它killall -KILL gedit。有时进程处于不可中断睡眠状态，这意味着它正在等待内核 I/O 操作，甚至无法通过这种方式终止。要检查这种情况，请killall -KILL gedit再次运行。按Ctrl+ Alt+F7切换回 GUI，现在它应该可以完全发挥作用了。
假设 GUI 功能齐全，问题就在于gedit与某个 GUI 组件之间的交互——可能是 X11 本身，也可能是您的窗口管理器（可能是、、compiz或其他，具体取决于您使用的图形界面）。这可能是由于 gedit 或窗口管理器（或 X11）中的错误造成的。在报告错误之前，最好先调查一下。metacityopenbox肖恩·戴维斯的建议很好。您应该找出您使用的是什么窗口管理器。这个问题可以帮你解决这个问题。在最近的 Ubuntu 版本中，3D Unity 使用compiz而 Unity 2D 使用metacity。如果你知道进程的名称，你可以使用ps命令和查看进程是否正在运行。例如，你可以使用查看是否正在运行或查看是否正在运行 metacity。正如 Sean Davis 所说，如果你正在运行 Unity，请尝试 Unity 2D（即，单击登录屏幕上的齿轮图标并选择grepps x | grep compizcompizps x | grep metacityUbuntu 2D），看看问题是否仍然存在。
启动错误报告流程
收集到这些信息后，继续报告错误。崩溃是指程序异常终止。此错误不是崩溃，因此不会有 .crash 文件，Apport 将无法自动运行以收集数据。但您仍然可以使用 Apport 收集一些相关数据以报告错误。有两种合理的方法可以做到这一点。
一种选择是运行ubuntu-bug，将包名称作为参数传递。这将收集有关包在系统上安装和配置方式的数据，并将其附加到您的错误报告中。您应该指定您认为最有可能导致问题的包。如果问题发生在 3D Unity（会话类型“Ubuntu”）中，但没有发生在 Unity 2D（会话类型“Ubuntu 2D”）中，那么它很可能在compizso run中ubuntu-bug compiz。（同样，如果问题发生在仅有的使用 Unity 2D，您可以运行ubuntu-bug metacity。）否则，继续使用 报告其gedit自身问题ubuntu-bug gedit。
运行ubuntu-bug compiz包含大量有关 的信息compiz，但ubuntu-bug gedit有关 的信息较少gedit。因此，如果您认为错误出在 中gedit，并且您愿意付出更多努力，您可能希望在gedit实际运行时调用 Apport，以包含有关正在运行的gedit进程的信息。由于您的 GUI 在发生错误时无法工作，因此您必须从虚拟控制台执行此操作，在上述步骤 2 和 3 之间。方法如下：
通过将选项卡从一个
gedit窗口拖到另一个窗口来重现该错误。执行上述说明中的步骤 1 和 2。
gedit通过运行命令来确定正在运行的进程的进程 IDpidof gedit。这将为您提供一个数字，即正在运行的进程的 PIDgedit。输入
script并按回车键。这将记录控制台上的所有文本。运行，但替换
apport-cli $PID$PID使用步骤 3 中确定的正在运行的编辑进程的进程 ID。在命令行上提供 Apport 请求的任何信息。您应该会得到一个 URL。它会很长而且看起来很随机，因此很难记住。这就是你跑去
script记录一切的原因。运行
exit（退出script）。gedit执行上述说明中的步骤 3、4 和 5 来终止并切换回 GUI。script创建了一个名为 的文件typescript，位于您的主目录中。找到此文件并使用gedit或其他文本编辑器打开它。从中复制 URL 并在您的网络浏览器中打开它。您将有机会在您的网络浏览器中编写错误报告。
编写并提交错误报告
无论您如何报告错误，您都将在 Web 浏览器中编写报告并提交。报告应尽可能详细。它应描述如何生成错误、软件包版本gedit以及您的窗口管理器提供的任何软件包（例如compiz或metacity），以及错误发生所需的条件的解释（例如，它是否发生在所有界面中，还是仅发生在 Unity 3D 中，或者其他）。
在提交错误报告之前，请务必阅读这一页如果你还没有这样做的话，请仔细阅读。
提交错误报告后，建议添加您认为可能受影响的其他软件包。通常，很明显哪个软件包受错误影响，但在这种情况下，情况并不完全清楚。即使问题发生在compiz而不是，仍然可能存在导致错误的metacity问题本身。gedit
如果您报告了与某个窗口管理器相关的错误compiz（或metacity其他窗口管理器），则可以将该gedit软件包添加为受影响的软件包。如果您报告了与该gedit软件包相关的错误，因为您能够使用至少两个不同的窗口管理器产生错误，那么您不应将任何窗口管理器软件包添加为受影响的软件包（除非您发现某个窗口管理器存在错误不是发生）。 相反，您可以添加xorg包。
要添加除最初报告错误的软件包之外的其他软件包，请转到 Launchpad 上的错误页面（如果您尚未进入）并单击Also affects distribution。指定Ubuntu为发行版（因为您说它会影响另一个软件包在 Ubuntu 中）。然后指定您认为可能受影响的附加包的名称，作为包名称。
如果列出了多个与该错误相关的软件包，则很可能（虽然不确定）除了一个之外的所有软件包都会被视为错误并被标记为无效。这没关系。但是，如果针对所有可能受到影响的软件包报告该错误，则您将为这些软件包的错误分类人员和开发人员提供机会来审查您的错误并确定他们是否认为该错误会影响他们的软件包。（但我强调通常你不应该这样做，因为通常也许可以在社区的帮助下，在报告错误之前弄清楚错误位于哪个软件包中。）
答案2
您使用的是什么环境？如果您使用的是 Unity 或 Gnome Shell，则可能与合成器有关。尝试使用 Unity 2D，看看是否会出现同样的问题。