Отладка

Эта страница об отладке ядра, языкового модуля или нативного плагина внутри запущенной игры, например сервера Counter-Strike 2. Об отладке плагинов на конкретном языке см. страницу «Отладка» этого языка в разделе Языки.

Сборка с символами

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

cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build

RelWithDebInfo даёт символы вместе с оптимизациями, это ближе к тому, что работает на боевом сервере. Замените библиотеку в папке envs сервера (или в папке bin хоста, если это ядро) на собранную.

Типы Plugify в отладчике

В папке debug репозитория ядра есть форматтеры для типов plg:: (строки, векторы, варианты):

• debug/vs/plg_types.natvis для Visual Studio: добавьте его в проект или в папку Visualizers Visual Studio;
• debug/lldb/plg_types_formatter.py для LLDB: загрузите командой command script import <путь>/plg_types_formatter.py или добавьте эту строку в ~/.lldbinit.

Отладка на Windows

Visual Studio 2022 может запустить игру под отладчиком.

1. Откройте исполняемый файл. Выберите File > Open > Project/Solution и укажите исполняемый файл игры, например cs2.exe в game/bin/win64.

2. Задайте командную строку. В свойствах проекта, Debugging > Command Arguments, введите аргументы, с которыми вы запускаете сервер, например -dedicated +map de_dust2.

3. Выберите тип отладчика. Для нативного кода достаточно Auto. Чтобы отлаживать ещё и C#-плагины, выберите смешанный режим (native и .NET Core).
4. Отключите перенаправление вывода. У игры своя консоль, которая не работает с перенаправленным выводом.
5. Запустите отладку клавишей F5. Если игра упадёт, Visual Studio остановится на месте падения со стеком и переменными.

Отладка на Linux

На Linux используйте GDB или LLDB, из командной строки или из IDE вроде CLion или VS Code. Запускайте бинарник сервера напрямую, чтобы отладчик видел весь процесс:

cd game/bin/linuxsteamrt64
gdb --args ./cs2 -dedicated +map de_dust2

В GDB run запускает сервер, bt печатает стек после падения, а break <функция> ставит точку останова. Точка останова в ещё не загруженном модуле или плагине ставится как отложенная и срабатывает, когда библиотека загрузится.

Падение можно разобрать и без подключённого отладчика: если система сохраняет дампы памяти, coredumpctl gdb открывает последний.

С чего начать

1. Отчёт о загрузке. После загрузки ядро пишет в лог, какие расширения не запустились и почему. Многие проблемы на этом и заканчиваются: неверный манифест, отсутствующая зависимость, библиотека, которую не удаётся загрузить.
2. Уровень логирования. Запустите хост с более подробным уровнем, чтобы видеть, что ядро делает шаг за шагом; S2-Launcher принимает --verbosity=<уровень>, см. Конфигурацию.
3. Минимальный пример. Воспроизведите проблему в plug только с нужными расширениями: он запускается за секунду, и его легко запустить под отладчиком.

Частые случаи

• Падение внутри плагина: нулевые указатели, уничтоженный объект, неверная сигнатура в манифесте. Проверьте, что paramTypes, retType и ref в манифесте совпадают с настоящей функцией.
• Неверные значения между языками: манифест экспортирующего плагина и биндинги вызывающего расходятся. Перегенерируйте биндинги после изменения манифеста.
• Производительность: используйте профилировщик, например perf или профилировщик Visual Studio, на сборке RelWithDebInfo.

Если застряли, спросите в Discord или откройте issue на GitHub.