- This topic has 10 replies, 2 voices, and was last updated 3 years, 2 months ago by
.
-
Posts
-
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.
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?
Hi,
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:
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
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.
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()).
Is gdb exiting because of the dropped telnet connection? Why would that happen? Should I check with my IT dept?
Sorry, we do now know why gdb is exiting. Based on the logs you submitted, it is not caused by VisualGDB.
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?
These toolchains are built based on the open-source tools such as GCC and GDB. They are provided free of charge and we are not aware of anyone who would agree to support them without directly billing for the time required to investigate the issues, sorry.
- You must be logged in to reply to this topic.