Dear all,
There is an issue with the gdb debugger plugin that causes occasional hangs in the plugin (it gets into a state where it doesn't accept user interaction anymore) with remote debugging (i.e. target {,extended-}remote). The lock up requires "Do *not* run debugee" to be unselected, i.e. it happens only if the debugger plugin starts the target immediately. The sequence of events is as follows:
When we issue the target {,extended-remote} command, gdb answers as follows:
> target extended-remote ...
Remote debugging using ...
0x00000abc in main () at main.c:123
123 for (;
{
>>>>>cb_gdb:
We then set m_QueueBusy = false in gdb_driver.cpp line 738, remove the top command from the queue, and rerun the queue at line 762. This will issue the next command, usually the first command out of the Additional GDB Commands tab, After connection text box. In my case this is monitor reset halt.
We then iterate over the gdb output response, and the 0x00000abc line matches reBreak2 in line 996. So we set the cursor and m_Cursor.changed = true in line 1008, and then m_needsUpdate = true in 1009.
Further down in line 1069, we set m_ProgramIsStopped = true and m_QueueBusy = false, and in line 1077, we rerun the queue, which means the current command (in my case monitor reset halt) is reissued without first awaiting for the prompt of the previous issue of the same command.
But we are now desynchronized with respect to the gdb prompts, we will use the acknowledgement of hte previous gdb command for the current gdb command.
Fast forward through the command sequence, we issue continue, which starts the target. But then we receive another cb_gdb: prompt, which we mistake as the target having stopped. We then issue a GdbCmd_FindCursor in line 1054, which sends info frame to the debugger, while the debugger is still running the target and not accepting commands. But the debugger plugin waits for an answer to the info frame command.
I'm on trunk revision 11304.
I am currently using the attached patch as a workaround for this.
