Open ValentinChirikov opened 1 year ago
Здравствуйте: 1) по нашему опыту поддержке автономного сервера в 8.3.20 много проблем с отладкой, рекомендую использовать версию 8.3.22 2) у себя мы тоже исправили часть ошибок поведения в рамках поддержки автономного сервера, надеемся на выход поддержки в 2023.1. 3) ошибку не считаю критичной, так как автономный сервер не заявлен на поддержку в EDT.
Описание ошибки
При отладке кода исполняемого на автономном сервере версии 8.3.20.1996 отладчик EDT 2022.2.3 при срабатывании брейкпоинта не показывает Серверный сеанс и не позволяет осуществлять переходы по коду
Как воспроизвести
dbgs –port=3550
Командная строка для запуска автономного сервера:
start /I "IB" "C:\Program Files\1cv8\8.3.20.1996\bin\ibsrv.exe" --data="C:\DevCloud\ss" --debug="http://127.0.0.1:3550" --config="conf.yml"
Файл настройки автономного сервера conf.yml
Скриншоты
Ожидаемое поведение
Отладчик долже успешно останавливаться на брейкпоинте и позволять переход по-коду
Лог рабочей области
exchg.log
Версия 1С:EDT
2022.2.3
Операционная система
Windows
Установленные плагины
No response
Дополнительная информация
В процессе отладки обнаружено: После аутентификации в клиентском приложения в метод
processEvent(DBGUIExtCmdInfoBase event)
объекта классаRuntimeEventDispatchJob
приходит объектevent com._1c.g5.v8.dt.debug.model.dbgui.commands.impl.DBGUIExtCmdInfoQuitImpl@154a0735 (cmdIDNum: 2, cmdID: targetQuit, targetIDStr: null, requestQueueID: null)
что приводит к вызову методаvoid removeThread(RuntimeDebugTargetThread thread)
объекта классаRuntimeDebugClientTarget
который удаляет поток отладчикаЕсли при отладке принудительно пройти этот обработчик - то система работает штатно. Вероятно что автономный сервер начинает сеанс отладки при запуске клиента до аутентификации, после чего удаляет этот сеанс. Это видно по объекту userName =
com._1c.g5.v8.dt.debug.model.base.data.impl.DebugTargetIdImpl@7c8cb579 (id: 917209b4-5d07-47bc-a4c2-2abe50a39c14) (seanceId: 4aa96b7d-bddf-44c8-a26a-7fe7cf35c691, seanceNo: 13, infoBaseInstanceID: 37a6640b-0706-40bd-9e36-ca424fd53b21, infoBaseAlias: exchg, isServerInfoBase: undefined, userName: <unset>, configVersion: 1ffb8a39e11be84fbe3ceeaf2090a98100000000, targetType: Server)
Это поведение соответствует отладки с помощью Wireshark
за исключением последнего шага, после которого, по-логике после слендующего ping() к отладчику должен подняться новый Target, но этого не проиходит.
Проблему удается обойти следующим "костылем"
или в качестве агента