Failed to allocate 0x0….. error

Sysprogs forums Forums VisualGDB Failed to allocate 0x0….. error

This topic contains 4 replies, has 2 voices, and was last updated by  en2 1 week, 1 day ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #21065

    en2
    Participant

    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

    Attachments:
    You must be logged in to view attached files.
    #21071

    support
    Keymaster

    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.

    #21072

    en2
    Participant

    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.

    #21073

    support
    Keymaster

    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.

    #21123

    en2
    Participant

    Greetings again,

    Upgrading Segger drivers to latest version seems to solve the problem for now 😀

    Thx

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.