Open UR3IQO opened 7 years ago
@sov1178 Looking at the logs, in the first one there are two things:
->=thread-exited,id="1",group-id="i1" 1: (1038) ->=thread-created,id="2",group-id="i1" 1: (1038) ->=thread-created,id="3",group-id="i1" 1: (1038) ->=thread-created,id="4",group-id="i1" 1: (1038) ->=thread-created,id="5",group-id="i1" 1: (1039) ->=thread-created,id="6",group-id="i1" 1: (1039) ->=thread-created,id="7",group-id="i1" 1: (1039) ->=thread-created,id="8",group-id="i1"
and
E output: {"category":"stderr","output":"ERROR: Unable to start debugging. Failed to find thread 1 for break event\r\n","data":null,"type":"output"} ERROR: Unable to start debugging. Failed to find thread 1 for break event
1: (1293) ->=thread-group-exited,id="i1" 1: (1296) <-logout
I would expect that if other threads are running, the thread-group that they belong to, in this instance i1
doesn't exit while its running.
I don't know if this is an issue in our code or an issue in the arm gdb version.
Thread 1 seems to exit early so we get the following error
@pieandcakes Thread 1 will always exit as soon as OS starts - it is not the real thread. OpenOCD makes fake thread to tell gdb that something is running before the OS starts. So it is OK. I do not know what caused thread-group exit message. I will see OpenOCD logs and write more.
I don't know if this is an issue in our code or an issue in the arm gdb version.
If I run gdb+OpenOCD with the same project/settings but without VSCode everything works finely, so it looks like it is related to VSCode.
Bump.
Exact same problem. Any solution?
I see the same on ESP32, but it disappears when I disable FreeRTOS support in the board configuration file. Sorry, don't have an ARM board at hand.
*) in my case "set ESP32_RTOS none"
Here is: cpptools v0.13.0 VSCode 1.16.1 Windows 8
I use VS Code to develop application for the ARM Cortem-Mx MCUs. When starting debugger with multithreaded application (with OpenOCD threads support) I need to run debugger session twice - first time VS Code drops debugging session. Standalone gdb-OpenOCD session runs flawlessly.
That is not a big problem, cause debugger functions properly after the second start, but it looks like something is broken.
Here is the debug log of the VSCode for the first debugger start: first.txt
And here is for the second one: second.txt
Note: when application starts there is no OS running yet, so OpenOCD reports there is a fake thread (thread id 1). This thread terminates on OS start and new real threads created.
The problem may be related to #978 issue.