Как в 1С определить, какие процедуры и функции вызываются в процессе работы?

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

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

Способ 1. Использование встроенного замера производительности

Замер производительности — один из наиболее наглядных способов получить сводный список всех процедур, функций и отдельных строк кода, которые были выполнены за определенный интервал времени.

Разберем по шагам, как правильно запустить и проанализировать замер, не дожидаясь закрытия программы:

  1. Откроем конфигуратор и подключимся к сеансу пользователя в режиме отладки.
  2. В главном меню выберем команду Отладка — Замер производительности (или нажмем соответствующую кнопку на панели инструментов). С этого момента платформа начинает протоколировать исполнение каждой строки кода.
  3. Перейдем в клиентское приложение и выполним пользовательское действие (нажмем кнопку, откроем документ или проведем операцию).
  4. Вернемся в конфигуратор и снова вызовем команду Отладка — Замер производительности, чтобы остановить процесс сбора данных.
  5. Сразу после повторного нажатия откроется окно с результатами, где указан список всех отработавших модулей, номеров строк, количество вызовов и чистое время их выполнения.

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

Полученные результаты замера можно сохранить через стандартное меню в файл формата .pmp. Такие файлы удобно выгружать для последующего детального разбора или загрузки в специализированные инструменты анализа.

Способ 2. Принудительная остановка отладчика и окно стека вызовов

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

Проанализируем алгоритм действий:

  1. Запустим выполнение целевой операции в пользовательском сеансе.
  2. В конфигураторе перейдем в меню Отладка — Остановить (или нажмем клавишу прерывания).
  3. Платформа приостановит выполнение кода на текущей активной строке.
  4. Откроем окно Отладка — Стек вызовов. В появившемся списке отобразится вся иерархия вложенности: от исходного события интерфейса до текущей процедуры нижнего уровня.
  5. Двойным кликом по любой строке стека вызовов мы можем мгновенно перейти к тексту соответствующего модуля и продолжить пошаговую отладку клавишами пошагового выполнения.

Почему точки останова могут не срабатывать?

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

  1. Сервер 1С запущен без режима отладки. В клиент-серверной архитектуре исполнение серверных процедур не перехватывается, если служба ragent запущена без специального параметра -debug. Проверим параметры запуска службы в операционной системе.
  2. Фоновые и регламентные задания. Значительная часть логики в современных конфигурациях выполняется асинхронно в отдельных фоновых потоках. Чтобы отладчик мог останавливать такие потоки, перейдем в меню Отладка — Подключение, нажмем кнопку Настройка автоматического подключения и обязательно включим флаг Фоновые задания.
  3. Кэширование после динамического обновления. Если в информационную базу применялись изменения конфигурации без перезапуска рабочих процессов («демоническое обновление»), исполняемый байт-код на сервере может не совпадать с текстом в конфигураторе. В таком случае помогает полный перезапуск клиентского сеанса или очистка локального кэша.

Перехват момента открытия формы через модуль менеджера

Если нам известен тип прикладного объекта (например, конкретный документ или справочник), но непонятно, какая именно форма открывается из-за динамической логики, поставим точку останова в модуле менеджера объекта в обработчике события ОбработкаПолученияФормы.

Посмотрим на пример перехвата формы:


Процедура ОбработкаПолученияФормы(ВидФормы, Параметры, ВыбраннаяФорма, ДополнительнаяИнформация, СтандартнаяОбработка)
    // Устанавливаем точку останова на строке ниже
    ТекстОповещения = "Инициализация формы: " + Строка(ВидФормы);
КонецПроцедуры

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

Альтернативные методы глубокого анализа вызовов

Рассмотрим дополнительные средства, если интерактивная отладка в конфигураторе затруднена:

  1. Режим «Остановка по ошибке». Если форма закрывается аварийно или ветка алгоритма прерывается скрытым исключением, включим через меню Отладка — Остановка по ошибке. Отладчик прервет поток управления ровно в момент возникновения ошибки с сохранением полного стека вызовов.
  2. Технологический журнал. Для сбора серверных трассировок без участия конфигуратора настроим файл logcfg.xml. События SCALL (клиентские вызовы) и CALL (серверные вызовы) со свойством Context позволяют сохранить в текстовые логи полный путь выполнения алгоритмов 1С.
  3. Профилирование в 1C:Enterprise Development Tools (1C:EDT). Если разработка ведется в среде EDT, встроенный инструмент профилирования умеет формировать визуальное дерево вызовов, детально отображая иерархию функций и затраченное время по каждой ветви алгоритма.
← На главную