Переход на новые версии платформы 1С:Предприятие (начиная с 8.3.25, 8.3.26 и заканчивая актуальной 8.3.27) часто преподносит неприятные сюрпризы для владельцев сильно доработанных или устаревших конфигураций. Одной из самых серьезных проблем является ошибка «Переполнение стека встроенного языка на сервере» при попытке формирования отчетов. Проанализируем, почему это происходит и какими способами можно восстановить работоспособность системы 1С:Управление нашей фирмой 1.6 без глобального обновления конфигурации.
Рассмотрим природу этой ошибки. Начиная с версии 8.3.25, разработчики платформы внесли существенные изменения в механизмы работы сервера приложений rphost. Был усилен контроль за использованием памяти и глубиной рекурсивных вызовов во встроенном языке. В старых редакциях БСП (Библиотеки стандартных подсистем), на которых базируется УНФ 1.6.19, механизмы построения схем компоновки данных (СКД) и разграничения прав доступа часто используют глубокую рекурсию.
Проанализируем ситуацию: когда пользователь запускает отчет, система начинает динамически формировать настройки и проверять доступные поля. Если в коде конфигурации есть цикличные зависимости в выражениях или слишком ветвистая логика обхода метаданных, новая платформа мгновенно прерывает процесс, выдавая ошибку стека, в то время как старые версии (например, 8.3.20) могли «проглатывать» такие операции за счет менее строгого лимита.
Разберем самый быстрый технический способ, который позволяет «успокоить» серверную часть. В каталоге установки платформы на сервере существует файл настроек conf.cfg. Мы можем явно указать системе, какой объем памяти выделять под стек вызовов.
Выполним следующие шаги по настройке:
C:\Program Files\1cv8\conf (или аналогичный путь, где установлена версия 8.3.27).conf.cfg с помощью текстового редактора от имени администратора.MaxStackSize. По умолчанию он может быть недостаточно велик для тяжелых запросов в СКД.Посмотрим на пример содержимого файла:
conf.cfg:
SystemLanguage=ru
MaxStackSize=512
Важно: Увеличение этого параметра до 512 или 1024 может помочь отчету сформироваться. После внесения изменений необходимо перезапустить службу Агент сервера 1С:Предприятия, чтобы настройки вступили в силу для всех процессов rphost.
Иногда проблема кроется в некорректной десериализации метаданных при первом запуске базы на новой платформе. Обычная очистка пользовательского кэша здесь не поможет. Нам необходимо выполнить полную очистку серверных временных файлов.
Проанализируем алгоритм действий:
srvinfo (обычно C:\Program Files\1cv8\srvinfo\reg_1541).snccntx. Также рекомендуется очистить папку configsave внутри каталога базы.Это заставит платформу 8.3.27 заново пересобрать модули и кэш метаданных, что часто устраняет фантомные ошибки переполнения стека.
Если вышеописанные методы не помогают, а отчеты критически важны, рассмотрим архитектурный подход, предложенный в обсуждении. Суть заключается в том, чтобы оставить проблемную базу на стабильной для нее платформе (8.3.20), а остальные задачи перевести на 8.3.27.
Разберем, как это реализовать при наличии обмена через COMConnector. Многие опасаются, что разные версии платформ не смогут взаимодействовать. Однако это не так. При вызове COM-соединения можно явно указывать версию платформы.
Посмотрим на пример кода для подключения к базе на другой платформе:
// Использование конкретной версии COM-соединителя
ВерсияПлатформы = "V83.COMConnector"; // Или V83.COMConnector.1 для регистрации конкретной DLL
Соединитель = Новый COMОбъект(ВерсияПлатформы);
// Параметры подключения к базе на другом сервере/порту
СтрокаСоединения = "Srvr='ServerName:1541';Ref='TradeBase';Usr='admin';Pwd='password';";
Попытка
БазаОле = Соединитель.Connect(СтрокаСоединения);
Сообщить("Соединение успешно установлено!");
Исключение
Сообщить("Ошибка подключения: " + ОписаниеОшибки());
КонецПопытки;
Выясним нюанс: чтобы это работало, на сервере, где выполняется код, должны быть зарегистрированы обе версии библиотеки comcntr.dll. Это делается через утилиту regsvr32. Таким образом, вы можете запустить два инстанса сервера 1С на разных портах (например, 1541 для 8.3.27 и 1641 для 8.3.20) и настроить обмен между ними.
Если ошибка возникает в конкретных отчетах, проанализируем код в Журнале регистрации. Обычно ошибка указывает на стек вызовов в общих модулях, связанных с УправлениемОтчетами или ПрефиксациейОбъектов.
Рассмотрим, что можно сделать программно:
Режим совместимости конфигурации. Для УНФ 1.6.19 это обычно 8.3.14. Попробуйте в копии базы поднять режим до 8.3.16. Это заставит платформу использовать другие алгоритмы компиляции кода, что иногда нивелирует проблему стека.Подводя итог, отметим, что наиболее эффективным и долгосрочным решением остается постепенное автоматическое обновление конфигурации (удобнее через перенос данных из старых конфигураций в УНФ 3.0) до актуальных релизов УНФ 3.0, где подобные ошибки платформы уже учтены в коде БСП, включая оптимизированные алгоритмы длительных операций. Однако для оперативного исправления ситуации на текущей базе связка из настройки MaxStackSize и очистки серверного кэша является приоритетной.