Работа с дампами и запрос в техподдержку 1С, если что-то пошло не так

Продолжаем публикацию статей по докладу «Дамп – не приговор, а повод задуматься», с которым выступили на осенней конференции INFOSTART TECH EVENT 2024. В первой и второй частях обсудили, как включать сбор файлов дампов для операционных систем Linux и Windows, что в себе содержат дампы и как анализировать эту информацию. В финальной статье продолжим рассказывать о том, чем может быть полезна информация, полученная из дампа.

Перед нами – дамп рабочего процесса сервера 1С, rphost. Мы же все помним, что rphost многопоточен? Так вот, чтобы увидеть активные треды внутри рабочего процесса, который завершился аварийно, необходимо выполнить команду «~*kb». На примере ниже показано 75 идентификаторов потоков, которые работали внутри рабочего процесса в момент аварийного завершения. Обратите внимание, что каждый из них содержит свой стек вызова функций.

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

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

Например: 

• dbgtgt – модуль, связанный с отладкой
• dcs – система компоновки данных
• moxel – модуль, связанный с работой в табличном документе
• escore – модуль, связанный с системой взаимодействия
• WTF – модуль, связанный с работой HTML и JSON 

В качестве примера рассмотрим один из этих модулей, именуемый WTF (Web Template Framework). Кейс: был проведен нагрузочный тест на 2000 пользователей. Среди них обнаружили 15 пользователей, у которых регулярно аварийно завершалось клиентское приложение 1С и формировался файл дампа. Проанализировав этот файл, обнаружили вот такой стек и задались вопросом, что это за модуль и к чему он относится.

Недолгие поиски помогли опознать модуль – он относился к движку WebKit, который отвечает за работу HTML. Далее проанализировали, что именно делают эти 10 сценариев нагрузочного теста, какие они открывают формы и каково содержание этих форм. В результате выяснилось, что в одном из сценариев в форме выводилась форматированная строка. После того, как ее заменили на обычную строку, ошибка пропала.

Теперь более подробно рассмотрим еще один кейс. В этой ситуации мы анализировали дамп, сформированный при аварийном завершении рабочего процесса. Сначала, конечно, посмотрели стек: heap_corruption, хм. Смотрим идентификатор аварийного потока и ищем среди всех именно его. Видите префикс «v8_» у некоторых имен модулей? Кстати, утилита Windbg при вызове команды «!analyze –v», показала, что не может проверить контрольные суммы в соответствующих временных файлах. А все потому, что мы имеем дело с вызовом внешнего компонента.

Как уже показывали ранее, ищем в списке загруженных модулей наш, и находим Datareon.Component.dll, который при обмене данными взаимодействует с корпоративной шиной данных.

Решение было довольно простым: обновили версию компонента до актуальной и порекомендовали клиенту обновить версию платформы 1С до 8.3.21 или выше и подключить внешний компонент изолированно, чтобы он функционировал в отдельном рабочем процессе. 

Но мы совсем забыли про Linux: как анализировать ТАКИЕ дампы?
Спойлер: все не так страшно, как может показаться на первый взгляд. На скриншоте представлен стек вызова функций.

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

На том же скриншоте показаны все активные потоки внутри, и здесь можно определить OSThread с помощью небольшого скрипта:
gdb -ex "core-file core.rphost.175193.app-1c.1710818743" -ex "info threads" -ex "quit" -batch | grep -E "^\*" | sed -E "s/.*LWP ([0-9]*).*/\1/" 

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

Инструкция: как составить квалифицированное обращение в техническую поддержку 1С 

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

1. архив с файлами дампов аварийного завершения
2. технологический журнал 1С, в котором есть данные на момент создания дампа со всех серверов кластера: ragent, rmngr, rphost, ras, dbgs 
3. реестр кластера 1CV8Clst.lst из каталога данных рабочего сервера, отмеченного как центральный 
4. для ОС Linux нужно собрать загруженные библиотеки зависимостей, которые использовал аварийный процесс. Как это сделать – в инструкции по ссылке 
5. данные по загрузке оборудования – эта информация может потребоваться в случае, если техподдержка 1С после анализа файла дампа заподозрит, что процесс мог аварийно завершиться, например, из-за нехватки оперативной памяти или перегруженности процессора. Поэтому рекомендуем подготовить метрики загрузки оборудования в момент формирования дампа: % загрузки процессора, доступная оперативная память, загруженность и время отклика дисков, использование swap 
6. информативное описание проблемы: что происходило во время сбоя, с какой частотой возникает аварийное завершение, у каких пользователей, при каком сценарии воспроизведения и другие подробности, которые помогут быстрее разобраться в ситуации. После подготовки информации обращение можно отправить через личный кабинет (РКЛ) или по почте v8@1c.ru 

Будет интересно: