Gedit вызывает сбой ОС [закрыто]

Какую среду Вы используете? Это могло бы быть связано с наборщиком при использовании Единицы или Gnome Shell. Попытайтесь использовать 2D Единицу и посмотрите, происходит ли та же проблема.

Предотвращение "жестких" перезагрузок

"Жесткие" перезагрузки почти никогда не необходимы. Если Вы находитесь когда-нибудь в ситуации, где Вы думаете, что, возможно, должны были бы сделать "жесткую" перезагрузку, необходимо попробовать эти альтернативы сначала в этом порядке:

1. Нажмите Ctrl+Alt+F1. Затем нажмите Ctrl+Alt+Delete. Это будет обычно чисто закрываться и перезагрузка.

2. Если это перестало работать, можно сделать что-то, что почти столь же мощно как "жесткая" перезагрузка, но которое уменьшает риск потери данных и другие возможные отрицательные результаты "жесткой" перезагрузки. Удержите Высокий звук и SysRq и, в порядке, нажмите R E I S U B. (Удержите Высокий звук и SysRq все время, но отпустите каждую клавишу буквы прежде, чем нажать следующую.) Видят эту страницу для простого объяснения того, что это делает, и эта статья Wikipedia для более подробной информации.

Однако в ситуации Вы встретились и описали в своем вопросе, это очень, вероятно, не необходимо для перезагрузки вообще. Существует техника, которая будет, вероятно, работать для завершения gedit но оставьте все остальное неповрежденным и полностью функционирующим. Можно даже сообщить об ошибке, хотя, так как это не на самом деле катастрофический отказ, это не будет с .crash файлом.

Восстановление без перезагрузки

Начиная с переключения рабочих областей возможно, система не заперлась полностью. Когда это происходит, необходимо смочь восстановить полное управление системой путем выполнения следующего:

1. Нажмите Ctrl+Alt+F1 для переключения от GUI до виртуальной консоли.

2. Войдите в систему со своим именем пользователя и паролем. Вы не будете видеть, что что-либо появляется на экране, поскольку Вы вводите свой пароль. Это в порядке.

3. Теперь, когда Вы имеете приглашение оболочки (как в Терминале приложение GUI), завершаете все gedit процессы с killall gedit. Обратите внимание на то, что Вы потеряете любую несохраненную работу в любом gedit окна/вкладки.

4. Выполненный killall gedit снова, чтобы видеть, работало ли это в первый раз. Если это говорит gedit: no process found это хорошо - это означает, что Вы успешно завершили gedit. Если это не говорит это, то gedit является небыстро реагирующим к SIGTERM ("хороший" способ попросить, чтобы процесс завершился). В этом случае завершите его с SIGKILL путем выполнения killall -KILL gedit. Иногда процесс находится в бесперебойном сне, что означает, что он ожидает на ядре операция ввода-вывода и не может даже быть завершен этот путь. Для проверки на это работать killall -KILL gedit снова.

5. Нажмите Ctrl+Alt+F7 для переключения назад на GUI, который должен теперь быть полностью функциональным.

Принятие GUI полностью функционально, проблема заключается во взаимодействии между gedit и некоторый компонент графического интерфейса пользователя - это мог быть сам X11, или это мог быть Ваш менеджер окон (который мог бы быть compiz, metacity, openbox, или что-то еще, в зависимости от того, какой графический интерфейс Вы используете). Это могло бы произойти из-за ошибки в gedit, или в Вашем менеджере окон (или X11). Прежде, чем сообщить об ошибке, это было бы лучшим, чтобы Вы исследовали это. Совет Sean Davis хорош. Необходимо узнать, какой менеджер окон Вы используете. Этот вопрос может помочь Вам с этим. В последних версиях Ubuntu, 3D использования Единицы compiz и Единица 2D использование metacity. Можно использовать ps команда и grep видеть, работает ли процесс, если Вы знаете его имя. Например, можно использовать ps x | grep compiz видеть, работаете ли Вы compiz или ps x | grep metacity видеть, выполняете ли Вы метагород. Как Sean Davis говорит, если Вы выполняете Единицу, попробуйте 2D Единицу (т.е. нажмите значок механизма на экран входа в систему и выберите Ubuntu 2D), и посмотрите, происходит ли проблема все еще.

Инициирование процесс создания отчетов ошибки

После того как Вы собрали эту информацию, разрешение и сообщаете об ошибке. Катастрофический отказ - когда программа завершается неправильно. Эта ошибка не является катастрофическим отказом, таким образом, не будет никакого .crash файла, и Apport не сможет работать автоматически для сбора данных. Но можно все еще использовать Apport для сбора некоторых соответствующих данных для того, чтобы сообщить об ошибке. Существует два разумных способа сделать это.

Одна опция состоит в том, чтобы работать ubuntu-bug, передача пакета называет как аргумент. Это соберет данные вокруг способа, которым пакет установлен и настроен в Вашей системе, и присоедините его к своему отчету об ошибках. Необходимо указать любой пакет, Вы думаете, скорее всего, вызывает проблему. Если проблема происходит в 3D Единице (тип сессии "Ubuntu"), но не в 2D Единице (тип сессии "Ubuntu 2D") затем, это находится, вероятно, в compiz таким образом выполненный ubuntu-bug compiz. (Точно так же, если проблема происходит только с 2D Единицей, Вы могли бы работать ubuntu-bug metacity.) Иначе, разрешение и отчет это против gedit самостоятельно с ubuntu-bug gedit.

Выполнение ubuntu-bug compiz включает большую информацию о compiz, но ubuntu-bug gedit включает меньше информации о gedit. Таким образом, если Вы думаете, что ошибка находится в gedit, и Вы готовы приложить дополнительные усилия, можно хотеть вызвать Apport в то время как gedit на самом деле работает, для включения информации о выполнении gedit процесс. Так как Ваш GUI не работает, когда ошибка происходит, необходимо было бы сделать это от виртуальной консоли между шагами 2 и 3 выше. Вот то, как:

1. Воспроизведите ошибку путем перетаскивания вкладки от одной gedit окно другому.

2. Выполните шаги 1 и 2 в вышеупомянутых инструкциях.

3. Определите идентификатор процесса выполнения gedit процесс путем выполнения команды pidof gedit. Это даст Вам число, PID выполнения gedit процесс.

4. Ввести script и нажмите Enter. Это записывает весь текст на консоли.

5. Выполненный apport-cli $PID, но замена $PID с идентификатором процесса рабочего редактирования обрабатывают, как определено на шаге 3.

6. Предоставьте любую информацию, которую Apport запрашивает по командной строке. Необходимо получить URL. Это будет длинно и случайно выглядеть, и таким образом очень трудно помнить. Вот почему Вы работали script записывать все.

7. Выполненный exit (для выхода script).

8. Уничтожить gedit и переключитесь назад на GUI путем выполнения шагов 3, 4, и 5 в вышеупомянутых инструкциях.

9. script созданный названный файл typescript, расположенное право в Вашем корневом каталоге. Найдите этот файл и откройте его с gedit или другой текстовый редактор. Скопируйте URL с него и откройте его в Вашем веб-браузере.

10. Вам дадут возможность записать отчет об ошибках в Вашем веб-браузере.

Запись и представление Вашего отчета об ошибках

Однако Вы сообщаете об ошибке, Вы будете писать отчет в своем веб-браузере и отправлять его. Отчет должен быть максимально подробно изложен. Это должно описать, как произвести ошибку, версию пакета для gedit и независимо от того, что пакет предоставляет Ваш менеджер окон (например, compiz или metacity), и объяснение того, какие условия требуются, чтобы ошибка произошла (например, делает она происходит во всех интерфейсах или только 3D Единице, или что-то еще).

Прежде, чем отправить Ваш отчет об ошибках, необходимо удостовериться, что прочитали эту страницу тщательно, если Вы так уже не сделали.

После представления отчета об ошибках желательно добавить любые дополнительные пакеты, Вы думаете, вероятно, будут затронуты. Обычно, ясно, какой пакет затронут ошибкой, но в этом случае, это не абсолютно ясно. Даже если проблема происходит с compiz и нет metacity, могла все еще быть проблема в gedit самостоятельно способствуя ошибке.

Если Вы сообщили об ошибке против compiz (или metacity или некоторый другой менеджер окон), можно добавить gedit пакет, как затронуто. Если Вы сообщили об этом по gedit пакет, потому что Вы смогли произвести ошибку по крайней мере с двумя различными менеджерами окон, затем Вы не должны добавлять пакет менеджера окон, как затронуто (если нет некоторый менеджер окон, с которым Вы нашли, что ошибка не происходит). Вместо этого можно добавить xorg пакет.

Для добавления другого пакета помимо того, против которого Вы первоначально сообщили об ошибке перейдите к странице ошибки на Панели запуска (если Вы уже не там), и щелчок Also affects distribution. Указать Ubuntu как распределение (так как Вы говорите это, влияет на другой пакет в Ubuntu). Затем укажите название дополнительного пакета, Вы думаете, может быть затронут, как имя пакета.

Больше чем с одним пакетом, перечисленным для ошибки, это вероятно (хотя не бесспорный), что все кроме каждого будут считать неправым и отмеченным Недопустимый. Это в порядке. Но сообщая об ошибке против всех пакетов, которые кажутся вероятными быть затронутыми, Вы даете ошибку triagers и разработчиков для тех пакетов возможность рассмотреть Вашу ошибку и определить, думают ли они, что она влияет на их пакет. (Но я подчеркиваю, что обычно Вы не должны делать этого, потому что обычно возможно выяснить, возможно, с общественной справкой, которые упаковывают ошибку, находится в прежде, чем сообщить об этом.)