Почему не срабатывает точка останова на сервере в 1С?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Причина 1: Точка останова установлена на неисполняемой строке кода

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

Именно с этой ситуацией столкнулся автор вопроса: точка была установлена на директиве объявления переменной:


Перем ОграниченияСписокСчетов;
Если ЗначениеЗаполнено(Параметры.ОтборПоПараметруБланка) Тогда
    // Исполняемый код
КонецЕсли;

Строка Перем ОграниченияСписокСчетов; сообщает компилятору о наличии локальной переменной, но сама по себе не выполняет никаких действий в рантайме. Как только точка останова была перенесена на следующую исполняемую строку с условием Если, отладчик сразу сработал штатно.

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

  1. Объявления локальных переменных с помощью ключевого слова Перем.
  2. Директивы препроцессора, такие как #Область, #КонецОбласти, #Если, #Иначе, #КонецЕсли.
  3. Заголовки методов: строки с ключевыми словами Процедура и Функция.
  4. Завершающие конструкции методов: КонецПроцедуры и КонецФункции.
  5. Пустые строки, а также строки, состоящие исключительно из символов комментариев.

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

Причина 2: Служба сервера 1С запущена без ключа отладки

Рассмотрим следующую распространенную ситуацию в клиент-серверном варианте работы. По умолчанию служба Агент сервера 1С:Предприятия запускается в рабочем режиме, при котором модуль отладки на стороне сервера отключен для снижения накладных расходов на производительность. При этом на клиенте отладка продолжает работать.

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

  1. Открываем реестр операционной системы Windows через команду regedit.
  2. Находим ветку службы 1C:Enterprise 8.3 Server Agent (путь зависит от версии платформы и разрядности службы).
  3. В параметре ImagePath находим строку запуска службы и добавляем ключ -debug.
  4. Перезапускаем службу агента сервера через оснастку управления службами.

Если сервер работает под управлением Linux, флаг -debug необходимо прописать в конфигурационном файле запуска демона (например, в параметре SRV1CV8_DEBUG=1 в файле настроек службы).

Причина 3: В Конфигураторе не настроено автоматическое подключение к серверу

Даже если служба сервера запущена с ключом -debug, отладчик в Конфигураторе должен знать, какие именно типы сеансов требуется перехватывать. Если серверный сеанс не подключен, остановка не произойдет.

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

  1. В главном меню Конфигуратора переходим в пункт Отладка — Подключение....
  2. Нажимаем кнопку Настройка автоматического подключения.
  3. Устанавливаем флаг Клиентские и внешние соединения на сервере.
  4. Если код вызывается асинхронно, обязательно включаем флаг Фоновые задания.
  5. Нажимаем кнопку подтверждения и перезапускаем сеанс отладки.

Причина 4: Рассинхронизация конфигураций из-за динамического обновления

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

В результате номера и смещения строк в запущенном сеансе расходятся с текстом модуля, открытым в Конфигураторе. Точка останова физически не может совпасть с выполняемой строкой.

Для решения проблемы очищаем локальный кэш конфигурации разработчика и перезапускаем рабочий процесс rphost либо полностью службу сервера 1С.

Причина 5: Блокировка портов сетевым экраном и протокол HTTP

В зависимости от используемого протокола (TCP или HTTP) отладчик и кластер серверов обмениваются данными по выделенным портам. Если на рабочем компьютере разработчика включен брандмауэр, входящие сетевые пакеты от серверного процесса rphost могут блокироваться. В этом случае сеанс на сервере замирает или игнорирует точку останова, так как не получает ответа от среды разработки.

При использовании современной отладки по протоколу HTTP проверяем доступность сервера отладки (Debug Broker) и сетевых портов между рабочим местом программиста и сервером приложений 1С.

Альтернативные способы контроля кода без точек останова

Если быстро восстановить работу отладчика не удается, а поведение серверной процедуры необходимо исследовать немедленно, рассмотрим альтернативные приемы диагностики:

  1. Запись в технологический журнал или журнал регистрации: используем процедуру ЗаписьЖурналаРегистрации, фиксируя передаваемые параметры формы и внутренние структуры данных.
  2. Искусственное исключение: временно добавляем в подозрительное место оператор ВызватьИсключение "Контрольная точка";. Это приведет к остановке программы и покажет стек вызовов и контекст исполнения в сообщении об ошибке.
← На главную