March 2, 2021 at 10:47 #30054
Having an issue where the visualgdb is killing a debug session after a minute or two. In the past I’ve seen the issue, and various combinations of deleting and reloading the OCD package, and installing a visual studio update have fixed the issue. But the issue has continued to come back after a period of time (weeks in some cases, a few days in the latest).
The error in the session log is always the same @”dropped ‘telnet’ connection (error -400)\n”
I’m on Visual Studio 2019 16.8.6
Visual GDB 5.5R4 Build 3920
Please tell me what other information you need to help with this.March 2, 2021 at 13:46 #30055
Here is a little additional info. I’m not sure if it is related.
After I posted last I tried removing and re-adding the OpenOCD package…that did not help. The debugging session still stopped after a few minutes.
Next I went to uninstall and reinstall VisualGDB. That gave me an error saying that a program called VcxprojReader had to be closed. Instead of continuing the uninstall I went to kill that program through Task Manager. There were 3 instances running. I killed them all through Task Manager. Now I have a debugging session that has been running for about 1 hour.
If the unexpected stop happens again, I’ll look for this process and kill it.
In the meantime…is that program even related to VGDB, or is this just a coincidence?March 3, 2021 at 14:13 #30058
Based on the description you provided, OpenOCD or gdb likely exits unexpectedly and hence VisualGDB ends the debug session.
We would advise checking OpenOCD logs and GDB logs for anything that could explain what is causing the session to end. You can find more about various diagnostic logs in the following pages:March 4, 2021 at 07:08 #30067
I captured all the logs I know to capture. I don’t see anything obvious. Please help.
Four files in this post. Two more files coming in next post.
openocd-tab in file name references which openocd tab in the error window (see png) the text was pulled from
Attachments:You must be logged in to view attached files.March 4, 2021 at 07:08 #30072
remaining two files mentioned above
Attachments:You must be logged in to view attached files.March 4, 2021 at 07:10 #30075
One strange thing to note in the logs above is that it mentions there being a breakpoint at the first line in main. I do not have a breakpoint set there. This is not the main problem, just some information.March 4, 2021 at 08:39 #30077
Thanks for the log files. This looks like the gdb executable itself exits unexpectedly. You can recheck this by killing arm-none-eabi-gdb.exe via Task Manager – VisualGDB will show the same message and same logs. The final -gdb-exit command is executed as a part of the regular cleanup sequence. In this case, GDB has already exited at that point.
If you would like to get to the bottom of it, you could try building a debug build of gdb itself, and attaching another debugger to it, but this is something to do at your own risk, sorry.
The breakpoint in main() is expected. VisualGDB sets it to support the “Step into new instance” command (starting the debug session with F10 instead of F5 to stop in main()).March 5, 2021 at 07:32 #30088
Is gdb exiting because of the dropped telnet connection? Why would that happen? Should I check with my IT dept?March 5, 2021 at 08:31 #30090
Sorry, we do now know why gdb is exiting. Based on the logs you submitted, it is not caused by VisualGDB.March 5, 2021 at 11:35 #30091
The toolchain with arm-none-eabi-gdb.exe was downloaded through visual gdb. Do you not support those toolchains? If not where can I go for support on that?March 5, 2021 at 11:45 #30092
You must be logged in to reply to this topic.