Home/ Questions/Q 793207
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T22:06:49+00:00

I’m using gdb to connect to a 2.6.31.13 linux kernel patched with KGDB over

  • 0

I’m using gdb to connect to a 2.6.31.13 linux kernel patched with KGDB over Ethernet, and when I try to detach the debugger I get this:

(gdb) quit
A debugging session is active.

 Inferior 1 [Remote target] will be killed.

Quit anyway? (y or n) y
Bogus trace status reply from target: E22

after that the session is still open, I can keep going on and on with ctrl+d, and the debugger doesn’t exit.

I’ve searched for that message in google and there are just 5 results (and none of them are useful :-/ ).

Any idea of what could it be and how to fix it?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If you cleared all breakpoints on the target and “C”ontinued from the latest breakpoint (assuming that the target code didn’t crash, etc.), I think you’ll be safe: when running, kgdb won’t be talking to your gdb anyway, since if I recall, it only handles the link when stopped (in a breakpoint or exception) awaiting for commands.
    A few Ctrl-C in a fast sequence if needed to get control back in gdb, then “q”, and that’s it.

    That’s at least my experience when debugging ko’s…

    I suspect gdb is saying this because it doesn’t realize that it is talking to a kgdb rather than to a remote gdb server. I don’t imagine kgdb accepting to kill a kernel thread because the debugger was exited, anyway!

    Hmmm, afterthought:
    You’re talking about kgdb ‘lite’, the one now part of the kernel tree, are you? Because that’s the only one I have experience with…

    PS on June, 3:

    I had never seen the exact message you mentioned until I moved to the 2.6.32 kernel (as part of the migration of my dev and target machines to Lucid). And then, surprise, I ran into it too. Here, it seems to happen in hopeless situations (like a segfault or kgbd seemingly running away after missing a breakpoint or single step). The only cure I have found so far was to pkill ddd (gdb) on the dev machine and reboot the target. But the good news is that the kgdb in 2.6.32 seems to be quite more stable than the one in Karmic (2.6.31).

    • 0