- This topic has 4 replies, 2 voices, and was last updated 5 years, 10 months ago by
.
-
Posts
-
Greetings,
I’d recently observed some sort of strange behaviour of my VisualGDB plugin (working on large project, lots of peripherals and interrupts, RTOS etc.). Almost 90 % of debugging attempts gets stucked, ending debugging session, crashing or even resetting VS.
Could it be somehow related to Visual Studio (using Community 2017). I have no such issues on other machine with the same setup (community + stm32 + j-link).
Attachning most common errors Im getting.
Regards,
Ernest
Hi,
This looks like a memory leak in the Segger GDB stub. If you are using VisualGDB with J-Trace, this is a known issue that was recently fixed by Segger in their development branch and should be soon available as a public hotfix. Please double-check with their support regarding specific plans for this.
This was observed using J-Link Plus (without trace). Why this error couldnt be reproduced in other IDEs (DS5, Keil) while using same programmer and same drivers? After googling a while, I couldnt find any information about possible memory leaks in segger stub past 2015.
Hi,
This is likely caused by the differences between the way J-Link is integrated in different IDEs. Older IDEs like Keil implement most of the debugging stack from scratch and only utilize low-level functions (like reading a specific memory location) from the J-Link DLL.
VisualGDB is built on top of the gdb debugger (that maps high-level requests like “get a value of a variable” into lower-level requests) that requires an extra component (Segger GDB stub) provided by Segger. Since we don’t have access to the source code of that component, unfortunately we are not able to diagnose issues that happen inside it, although it should be covered by the regular Segger support.
Another option would be to try using OpenOCD instead of the Segger GDB stub (you can switch it via VisualGDB Project Properties). OpenOCD is less polished than the Segger gdb stub, especially when it comes to supporting non-mainstream devices, however there are no memory leaks in it that we are aware of.
Hope this explains. Let us know if you have any further questions.
- You must be logged in to reply to this topic.