Recently I have been running into the following error message in Eclipse when I started the GDB debugger:
The error details do not show much more:
Error in final launch sequence Failed to execute MI command: continue Error message from debugger back end: Cannot execute this command without a live selected thread. Failed to execute MI command: continue Error message from debugger back end: Cannot execute this command without a live selected thread. Cannot execute this command without a live selected thread.
It does not happen all the time, but it happens often with the Segger J-Link GDB server. It does not happen for ‘small’ programs (say less than 50 KByte). But it happens more often for larger programs (say > 100 KByte of FLASH).
I have enabled GDB Traces (see “Board Bring-Up Tips, GDB Logs and Traces in Eclipse” how to enable GDB Traces) to get more information about the problem:
688,887 (gdb) 688,888 &"flushreg\n" 688,888 ~"Register cache flushed.\n" 688,888 45^done 688,888 (gdb) 688,888 &"continue\n" 688,888 ~"Continuing.\n" 688,888 &"Cannot execute this command without a live selected thread.\n" 688,888 46^error,msg="Cannot execute this command without a live selected thread." 688,888 (gdb) 688,889 47-gdb-exit 688,898 47^exit 688,906 =thread-group-exited,id="i1"
Googling around, it seems that GDB throws this message if GDB receives a command, but has not initialized properly yet. So to me it seems that GDB is still busy with doing things after the download, and then it receives a command (in my case the ‘continue’ command), and is not ready yet.
The problem is that with that error message above, I have to restart the download/flashing again.
I have not found a solution, but found at least a workaround. Because there seems to be a race condition with the download and the ‘continue’ execution, I have disabled the ‘continue’ in the GNU ARM Eclipse/GDB launch configuration:
That way, GDB is not instructed to do a ‘continue’ after the download. So it will stay on the reset vector/startup. Then I simply do a ‘continue’ in the debugger UI. I searched for a ‘wait for x ms’ function in the GDB command list, but have not found anything suitable for this situation.
That would have been another workaround: say wait 500 ms after the download until executing the ‘continue’ command.
Thanks to John (see comments) there is an even better solution: The Segger GDB server accepts a timeout command, e.g. to wait 500 ms:
monitor sleep 500
That way, the problem was solved for me too :-).
There seems to be a timing problem between the GDB server and client. As a workaround I do not configure GDB to continue execution after downloading.
Happy Continuing 🙂