GDB Prompt Hangs after Pressing Tab in a "Command List"

[jhxie]

Bug Behavior:
Like the image shows, the GDB prompt will hang(no longer accept any input) after I pressed [TAB] in a "command list", which is attatched to a hardware watchpoint by setting a watchpoint on a strcuture "confinfo", then type "commands 2".
Details:
The situation here is that I can still return back to the source code window by using [ESC], but after I was brought back to the GDB prompt by typing [i] the prompt will not accept any input because I pressed [TAB] to try to complete "printf"' so the only thing I can do is to quit by tying ":quit" in the source window.
Platform:
x86-64 Archlinux running 4.1.10-2-lts kernel
CGDB 0.6.8 from default pacman repository
Thank you for looking into this issue!

[scottlu]

This problem is being caused by a bug in the CGDB's implementation of the GDB/annotate-2 protocol.

When you press tab, CGDB sends GDB a "server complete " command, then normally GDB replies with the completion results. CGDB then updates readline with the new updated line, and updates the screen.

But, when GDB is waiting for you to enter breakpoint commands it doesn't offer a response to the "server complete " command, and this causes CGDB's annotate-2 state machine to get confused.

CGDB's annotate-2 state machine has the same state value for the normal prompt vs. the "enter breakpoint commands" prompt. This could be differentiated to fix the bug, however there is talk of moving to the GDB/MI protocol, which would make this issue moot.

[brasko]

I'm working towards a patch for this. At a minimum, I'll try to ignore tab completion in this situation rather than completely ruin the debugging session. I'll probably not get this into the next release, but most likely we'll release more regularly for a while.

[brasko]

This should be fixed in the new-ui branch. Please let me know. Thanks.

[brasko]

Fixed in master