← На главную

При переходе на протокол HTTP-отладки в платформе 1С:Предприятие 8.3 разработчики и администраторы часто обращают внимание на то, что запущенный процесс сервера отладки dbgs (или dbgs.exe) отображается в диспетчере задач или списке процессов без параметра --ownerPID (или OWNERPID). Разберем, за что отвечает этот параметр, влияет ли его отсутствие на процесс отладки и с какими сопутствующими особенностями можно столкнуться при отладке конфигураций и внешних обработок.

Назначение и роль параметра --ownerPID в процессе dbgs

Проанализируем механизм управления жизненным циклом сервера отладки. Параметр --ownerPID=<PID> предназначен исключительно для привязки процесса dbgs к идентификатору родительского процесса (например, Конфигуратора или агента кластера ragent). Он сообщает серверу отладки, что при завершении работы (штатном или аварийном) родительского процесса процесс dbgs должен автоматически завершить свою работу и освободить системные ресурсы.

Если сервер отладки запущен без ключа --ownerPID, это означает следующее:

1. Процесс запущен независимо — вручную из командной строки, через командный файл скрипта или как отдельная служба операционной системы (демон в Linux или служба с ключом --service в Windows).
2. Работоспособность не нарушается — сервер отладки функционирует в штатном режиме, слушает назначенный TCP-порт (по умолчанию 1550) и корректно обрабатывает входящие подключения от сеансов 1С и Конфигуратора.
3. Контроль завершения возлагается на ОС или пользователя — процесс dbgs не выгрузится из памяти автоматически при закрытии Конфигуратора и продолжит работать в фоновом режиме.

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

Ограничения автономного сервера отладки и настройка клиент-серверного режима

Рассмотрим важное архитектурное ограничение платформы при автономном запуске сервера отладки как отдельной службы:

1. Через отдельно запущенный экземпляр dbgs доступна полноценная отладка файловых информационных баз, а также клиентских контекстов (модули форм, модули команд) в клиент-серверных базах.
2. Для отладки серверного контекста в клиент-серверном режиме (серверные вызовы, модули объектов, фоновые и регламентные задания) отдельная служба dbgs не подходит. В этом сценарии сервер отладки должен запускаться непосредственно кластером серверов 1С. Для этого в параметры запуска службы ragent добавляются ключи -debug -http.

Особенности отладки общих модулей с признаком повторного использования

Разберем частую ситуацию, когда точка останова в общем модуле срабатывает только при первом вызове, а при повторных обращениях отладчик не переходит в тело функции. Выясним причину такого поведения.

Если у общего модуля установлено свойство Повторное использование возвращаемых значений в значение На время сеанса или На время вызова, платформа кэширует результат первого вызова функции для переданного набора параметров. При повторных вызовах с теми же значениями аргументов тело функции физически не исполняется — платформа сразу возвращает сохраненное в кэше значение. Соответственно, отладчик в код функции повторно не заходит.

Для принудительной отладки алгоритмов в таких модулях применим следующие приемы:

1. Программный сброс кэша: перед точкой вызова функции вызываем метод встроенного языка для очистки кэша повторного использования:
   Скопировать код

   
   // Очищаем кэш повторно используемых значений в текущем сеансе
   ОбновитьПовторноИспользуемыеЗначения();
   Результат = МойОбщийМодульПовтИсп.ПолучитьДанные(Параметр1);
   

2. Передача фиктивного динамического параметра: если в функцию временно добавить параметр, меняющийся при каждом вызове (например, текущее время с миллисекундами), кэш будет инвалидироваться при каждом вызове:
   Скопировать код

   
   // Значение в кэше обновляется из-за смены аргумента
   ФиктивныйКлюч = ТекущаяУниверсальнаяДатаВМиллисекундах();
   Результат = МойОбщийМодульПовтИсп.ПолучитьДанные(Параметр1, ФиктивныйКлюч);
   

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

Обеспечение стабильности HTTP-отладки

Посмотрим на параметры, обеспечивающие стабильное сетевое соединение с сервером отладки:

1. В сетевом экране (брандмауэре) сервера и рабочих станций необходимо открыть доступ к порту отладки (по умолчанию 1550 TCP) или к диапазону портов, если задан ключ --range.
2. При нестабильном автоматическом обнаружении отладчика или сложной топологии сети адрес сервера отладки можно зафиксировать напрямую в дополнительных параметрах запуска клиента или Конфигуратора с помощью ключа: /DEBUGGERURL "http://адрес_сервера:1550"

Таким образом, отсутствие ключа --ownerPID у процесса dbgs не является ошибкой конфигурации и не снижает функциональность отладки при условии корректной настройки сетевых портов и параметров кластера 1С.