Если вы очистили все точки останова на цели и «C» были продолжены с последней точки останова (при условии, что целевой код не аварийно завершился и т. Д.), Я думаю, вы будете в безопасности: при запуске kgdb не будет в любом случае говорить с вашим GDB, так как, если я вспоминаю, он обрабатывает ссылку только тогда, когда остановлен (в точке останова или в исключении) в ожидании команд.
Несколько Ctrl-C в быстрой последовательности, если необходимо вернуть контроль в gdb, затем «q», и все.
Это, по крайней мере, мой опыт отладки ко ...
Я подозреваю, что GDB говорит это, потому что не понимает, что говорит с килограммом, а не с удаленным GDB-сервером. Я не представляю, что kgdb согласился уничтожить поток ядра, потому что отладчик был закрыт!
Хммм, запоздалая мысль:
Вы говорите о kgdb 'lite', который теперь является частью дерева ядра? Потому что это единственный, с которым у меня есть опыт ...
PS 3 июня:
Я никогда не видел точное сообщение, о котором вы упомянули, пока не перешел на ядро 2.6.32 (как часть миграции моей машины разработки и назначения на Lucid). И потом, к удивлению, я тоже столкнулся с этим. Здесь, кажется, это происходит в безнадежных ситуациях (например, segfault или kgbd, которые, казалось бы, убегают после пропуска точки останова или одного шага). Единственное лекарство, которое я нашел до сих пор, - это pkill ddd (gdb) на машине разработчика и перезагрузка цели. Но хорошая новость заключается в том, что kgdb в 2.6.32 кажется более стабильным, чем в Karmic (2.6.31).