Адаптер не найден или не запускается¶

Симптом: окно открывается, но ничего не происходит; либо сессия сразу падает в failed; либо :DebugStart сообщает об ошибке и останавливается.

Что говорит лог¶

Откройте панель Logs (Ctrl+L) и включите Session. Обычно там есть одно из следующего:

Строка лога похожа на	Причина	Идти в
команда адаптера не найдена	его нет в `PATH`	1
адаптер стартовал и сразу умер	падает сам адаптер	2
`program is not readable`	по этому пути нечего отлаживать	3
`launch` отклонён с сообщением	адаптер возражает против запроса	4
нет конфига и не опознан язык	проекта попросту нет	5
сборка не удалась, с выводом компилятора	программа не компилируется	6

1. Адаптера нет в `PATH`¶

Причина номер один с большим отрывом.

command -v codelldb
command -v dlv
command -v php-dbgp-adapter
python3 -m debugpy --version

Если проверка ничего не напечатала, адаптер не виден. Учтите: он может быть виден вам и не быть виден Bugsaur — окно, запущенное из Neovim, наследует окружение Neovim, а оно может отличаться от вашего шелла.

export PATH="$HOME/.local/share/nvim/mason/bin:$PATH"   # Mason
export PATH="$PWD/target/debug:$PATH"                   # php-dbgp-adapter

Более надёжное решение — назвать бинарник в профиле, вообще обойдя PATH:

[profiles.api]
adapter = "codelldb"
adapter_command = "${root}/vendor/codelldb"
program = "target/debug/api"

2. Адаптер стартует и умирает¶

Включите в логе категорию Adapter — она несёт собственный stderr адаптера, и причина обычно изложена там его же словами.

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

Адаптер	Сообщение	Что делать
`debugpy`	`No module named debugpy`	поставьте его в интерпретатор из `adapter_command`
`dlv`	расхождение версий Go	встроенная запись уже передаёт `--check-go-version=false`; в своём каталоге его может не быть
`codelldb`	не найдена разделяемая библиотека	переустановите CodeLLDB под эту платформу
`php-dbgp-adapter`	порт занят	его держит другой проект — задайте этому свой `port`

3. `program` не существует¶

ls -l "$(pwd)/target/debug/my-binary"

Помните, что означает program в разных языках: собранный бинарник для Rust и C/C++, каталог пакета для Go, скрипт для Python, каталог проекта для PHP.

Bugsaur собирает только для тех адаптеров, у чьей записи каталога есть build — на практике это Go. Rust и C/C++ вы собираете сами:

cargo build

4. `launch` отклонён¶

Адаптер получил запрос и возразил. Сообщение приходит от него самого и обычно называет проблемный ключ.

Здесь стоит проверить launch_arguments: он передаётся без изменений, и ключ заменяет то, что сгенерировал Bugsaur, а не сливается с ним. Случайный mode, program или cwd внутри меняет запуск полностью.

Включите категорию DAP, чтобы увидеть в точности отправленное тело.

5. Нет конфига и не опознан язык¶

Ошибка называет каталог, на котором поиск сдался. Значит, он дошёл вверх до конца дерева и не нашёл ни .bugsaur/config.toml, ни маркера языка.

То же сообщение бывает у Python-проекта, где маркер есть, а точки входа с известным именем нет — main.py, app.py, manage.py, __main__.py, src/<pkg>/__main__.py. Выдумывать её отладчик не станет.

Напишите конфиг руками, он короткий. См. Настройка → Профили.

6. Сборка не удалась¶

Сессия падает в failed с текстом компилятора, а адаптер не поднимается вовсе — намеренно, потому что отладка устаревшего бинарника была бы хуже.

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

go build ./cmd/api
cargo build

Всё ещё не работает¶

Сохраните лог (Save в панели Logs пишет весь буфер независимо от фильтров) и сверьтесь с Чтением логов.