Если в процессе работы вы столкнулись с проблемой или у вас есть сомнения в том, что 1C:EDT работает правильно, можно предпринять следующие действия.
Если вам кажется, что ничего не происходит, откройте панель Состояние или посмотрите в правый нижний угол основного окна. Возможно, 1C:EDT занята работой, просто вы этого не замечаете.
Панель Состояние показывает прогресс выполнения длительных фоновых операций: при импорте конфигураций, при построении модели проекта и в других случаях.
Если вы столкнулись с непонятным сообщением, посмотрите список известных проблемных ситуаций.
Если вам кажется, что один из редакторов работает неправильно, вам может помочь следующая последовательность действий:
Одной из причин неправильной работы могут являться нарушения в модели проекта. Можно построить проект заново.
Проекты будут очищены и их внутренняя модель будет построена заново, как при импорте конфигурации из информационной базы:
Другой причиной неправильной работы могут являться нарушения в работе сервисов, обслуживающих модели проектов. В этом случае может помочь перезапуск 1C:EDT.
Чтобы сделать это, нажмите
.Для воспроизведения и анализа неправильной работы техническая поддержка может запросить у вас лог или журнал ошибок.
Чтобы сформировать этот файл для 1C:EDT:
Этот же журнал ошибок содержится в .log-файле в вашей текущей рабочей области, в каталоге .metadata.
Чтобы получить .log-файлы для 1C:EDT Start:
Интерфейс командной строки имеет опцию -timeout, которая задает максимальное время, отводимое на выполнение команд. Если выполнение не завершилось по истечении этого времени, оно будет прервано и будет записан дамп потоков, который может помочь расследовать причину зависания.
Дампы записываются в вашу текущую рабочую область в каталог .metadata. Они имеют имена:
1cedtcli-thread-dump.<pid>.<index>.txt
Если 1C:EDT долгое время не реагирует на ваши действия и нет никаких видимых оповещений о том, что выполняется какое-то длительное действие, то можно считать, что 1C:EDT «зависла». В этом случае для расследования ошибок мы рекомендуем сразу, не дожидаясь ответа от разработчиков, снять дамп потоков и дамп памяти, чтобы передать их в службу технической поддержки.
Обычно для расследования «зависаний» хватает дампа потоков выполнения приложения. Чтобы снять дамп потоков, можно воспользоваться стандартной утилитой jstack, которая входит в состав Java Development Kit ( JDK). Для снятия дампа потоков необходимо выполнить в командной строке:
jstack -l 22668 > threaddump.txt
Здесь 22668 — это PID (process identifier) процесса javaw.exe. Можно узнать его через диспетчер задач (в зависимости от операционной системы).
Также получить PID можно из командной строки или используя терминал:
Windows 10
tasklist /fi "IMAGENAME eq javaw.exe"
Linux
ps aux | grep 1cedt
Как правило, требуется дамп процесса javaw.exe, но если файл конфигурации запуска 1C:EDT (1cedt.ini) не изменялся, то нужен дамп оригинального процесса 1cedt.exe.
Путь и имя файла выгрузки дампа в приведенном примере указан после символа «>». Если указано только название файла, то дамп сохранится в директории, из которой была запущена командная строка или терминал.
<PID>: no such process
Если выполнение предыдущей команды jstack -l
приводит к сбою подключения, тогда необходимо запустить утилиту с флагом -F:
jstack -F 22668 > threaddump.txt
Полученный файл threaddump.txt (дамп потоков) необходимо передать в службу технической поддержки.
Чтобы снять дамп памяти, можно воспользоваться стандартной утилитой jmap, которая входит в состав Java Development Kit ( JDK). Для снятия дампа памяти необходимо выполнить в командной строке:
jmap -dump:format=b,file=memorydump.hprof 22668
Здесь 22668 это PID (process identifier) процесса javaw.exe. Можно узнать его через диспетчер задач (в зависимости от операционной системы).
Также получить PID можно из командной строки или используя терминал:
Windows 10
tasklist /fi "IMAGENAME eq javaw.exe"
Linux
ps aux | grep 1cedt
Как правило, требуется дамп процесса javaw.exe, но если файл конфигурации запуска 1C:EDT (1cedt.ini) не изменялся, то нужен дамп оригинального процесса 1cedt.exe.
Путь и имя файла выгрузки дампа в приведенном примере указан в параметре «file=». Если указано только название файла, то дамп сохранится в каталоге, из которого была запущена командная строка или терминал.
Heap dump file created
При возникновении проблем будет показано сообщение об ошибке. Например, если не найден PID, то будет выведено сообщение:Exception in thread "main" java.io.IOException: no such process
Если выполнение предыдущей команды jmap -dump
приводит к сбою подключения, тогда необходимо запустить утилиту с флагом -F:
jmap -dump:format=b,file=memorydump.hprof -F 22668
Полученный файл memorydump.hprof (дамп памяти) необходимо передать в службу технической поддержки.
Когда все необходимые дампы получены, можно закрыть 1C:EDT. Если интерактивно это сделать не получается, можно либо воспользоваться диспетчером задач (в зависимости от операционной системы), либо завершить процесс, выполнив в командной строке:
kill -f 22668
Здесь 22668 это PID (process identifier) процесса 1C:EDT.
Панель Журнал ошибок показывает все предупреждения и ошибки, записанные плагинами Eclipse в лог-файл. Этот лог-файл находится в каталоге .metadata рабочей области.
Панель заполняется данными автоматически. Над списком событий расположено поле поиска. С его помощью можно отобрать события, содержащие некоторый фрагмент строки.
Адрес багтрекера — https://github.com/1C-Company/1c-edt-issues
На этом багтрекере можно регистрировать ошибки и пожелания, относящиеся к 1C:EDT.
В интерфейсе 1C:EDT существует кнопка (Сообщить о проблеме), которая позволяет быстро опубликовать ошибку на багтрекере, не отвлекаясь от контекста работы.
Для использования этой фунции вам нужно иметь учетную запись на портале GitHub, а также токен доступа:
Эти данные нужно указать в настройках отправки отчета
: