[SOLVED] possible memory leak when using JLink\SDK

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] possible memory leak when using JLink\SDK

    Dear All,

    I encounter a memory allocation failure when using JLink SDK, I was wondering if you could shed some light on the source of it.

    My program uses a DLL to communicate with ARM thru teh SDK. It opens/close connection to the core in an endless loop using (eventually) JLINKARM_Open() and JLINKARM_Close()

    After ~450 iteration, I get a Windows error that it failed to allocate 0x00400000 bytes of memory, followed by the following JLINK 4.86a internal pop-up messages: TRACEBUF: could not alloc global buffer for trace data.

    In an attempt to find the source of the problem I'm using visual leak detector which reports that the leak started at JLINKARM_PERIODIC _Control - which is a function I don't call at all.

    Could you explain what is the source of the JLINK error message and how can I avoid it?

    Many Thanks!
    Hila Miranda-Kuzi
  • Dear Hila Miranda-Kuzi,

    We have fixed / improved some "issues" related to the trace module in later versions of the J-Link software.
    Can you please check if you are able to reproduce this behavior using the latest J-Link DLL (V4.96h)? The version is available for download here: segger.com/jlink-software.html

    We tried to reproduce this with both, the old V4.86a and the latest version V4.96h but we are not able to see this behavior.
    We created an application which calls JLinkARM_Open() and JLINKARM_Close() in an endless loop. After > 2000 loops, everything works just fine.

    Please let me know if you see this behavior with the latest version to, so we can check for differences between your and our setup.


    Best regards
    Erik
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Eric,

    we left this issue for quiet a while, but returned in an attempt to solve it once and for all. I'ts killing us!

    I made some progress in isolating the problem, attached please find a zip containing a visual studio 2012 solution (ARM9_IFD.sln) which reproduces it.

    The solution contains two projects:
    *) ARM9_IFD - generates a ARM9_IFD.dll, a dll based on your SDK with two functions - core_open and core_close, which activate JLINKARM_Open() and JLINKARM_Close()
    *) Jlink_test - a main program (executable) which loads the library ARM9_IFD, gets the processes for core_open and core_close that performs open and close using the DLL. The executable performs a loop of 0x300 calls to core_open and core_close.

    After several iteration we get a windows error message (see win_error.jpeg) or access violation.

    If I replace the call to ARM9_IFD.dll core_open and instead call JLINKARM_Open() from my executable (main.cpp line 56 which is commented out), there is no corruption.
    This hints that perhaps the problem occurs only when using JLink SDK thru a DLL.

    I executed the test with "Visual Leak Detector", which resulted in a terrible memory corruption (see vld_dump.jpg) and an endless dump of error messages.

    Version in use:
    JLinkArm.dll is taken from version 500i
    JLink SDK is version 462

    Please contact me about details on how to execute the test it it is not clear enough.

    Many Thanks!
    Hila
    Images
    • win_error.jpg

      54.33 kB, 759×424, viewed 827 times
    • vld_dump.jpg

      517.12 kB, 1,920×1,080, viewed 846 times
  • Hi Hila Miranda-Kuzi,

    we left this issue for quiet a while, but returned in an attempt to solve it once and for all. I'ts killing us!
    Please note that we have waited for a reply from you (see post below).
    I made some progress in isolating the problem, attached please find a zip containing a visual studio 2012 solution (ARM9_IFD.sln) which reproduces it.
    I have just deleted the attachment as sharing the source code / DLLs of the SDK is in violation of the J-Link SDK license agreement. For further information, please refer to the License.txt which is part of the SDK package itself.

    I have downloaded the package before and we will try to squeeze this in sometime this week.

    Anyhow, I will get back to you regarding this via E-Mail, so we do not have to care about violation of the J-Link SDK. We will post the results here in this thread.


    Best regards
    Erik
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Thanks for your support,

    As I wrote, we put this issue on hols for quiet a while by overcoming it is creative manners (reducing number of resets, partitioning of test package to sub-modules, and ugly solutions)

    It's not urgent, we get-by, but I appreciate your support. We have quiet a few JLink based setups that suffer from it.

    Please contact me if you need any more data.

    Thanks!
    Hila
  • Hi Hila Miranda-Kuzi,

    we are able to reproduce the issue with your project files. A corresponding fix will be part of a newer version. There is a workaround you can use.
    Calling the functions LoadLibrary and FreeLibrary only once at runtime (outside of the while-loop) will work reliable.

    Would this be suitable for you for at this moment?

    Best regards,

    Roman
  • Hello Roman,

    Thank you very much for your efforts.

    I'm afraid using only LoadLibrary and FreeLibrary only once is not an option. We use the JLink SDK as part of quite a large SW stack, which supports several cores, each may be accessed by several sources. We make sure all open/close tasks do not leave a trace so that other sources can access the same cores, etc.

    However, we can do without the fix for a while longer, we made some ugly and creative workarounds to overcome this issue which allow us to complete a few hundreds of iterations before the crash.

    I would like to know however an estimated time for next fixed release. Is it the SDK or the JLink DLL?

    Will you notify me when the fix is available for download?

    Many Thanks!

    Hila
  • Hi Hila,

    I would like to know however an estimated time for next fixed release. Is it the SDK or the JLink DLL?

    Not sure what you mean.
    The SDK is mainly the DLL + some samples + documentation.
    The fix of course needs to be done in the DLL (which is the only part of the SDK used in your application)

    Will you notify me when the fix is available for download?

    The fix will be mentioned in the regular notifications for the SDK.
    Assuming that you are in the valid support and update period (please check internally) you or the contact being mentioned at the time of purchase, will get the notification, once the version is available.

    Timeframe: Planned in app. 4 weeks, as this requires some larger internal re-structuring.


    - Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello once more,

    Please let us know a target date for the release of the SDK?
    Our support center assured us that Segger is currently working on a solution. This was about a month ago.
    Please update on the target date for a release of an SDK with a fix.

    Many Thanks!
    Hila
  • Hi Hila,


    unfortunately, we did not have the resources available to fix this issue yet.
    In general, we strictly prioritize bug fixing over anything else, but in this case
    - You were the only one facing this issue. We did not receive a single inquiry via e-mail or this forum from someone within an active J-Link SDK support period.
    - Fixing this issue does not only require a decent amount of time, it also demands a chunk of time to be invested in making sure that no backwards compatibly is broken due to the substantial changes to basic concepts of the DLL required to fix this behavior.
    -We had some setbacks regarding available manpower

    However, we brought this issue back to our priority list.
    We plan to release a fixed and tested version by the end of November. A beta / preliminary version may be available sooner.

    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Hila,

    i sent you a PM with a link to a preliminary version.
    Any feedback is highly appreciated.

    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Niklas

    Good news, I was not able to reproduce the failure using the new dll.

    I tried a "synthetic" DLL open/close program and an exhaustive functional test and they both completed without the memory overflow.

    Do you recommend that we move to the new DLL as production version? In any case, we are keeping one system alive with the new DLL and report if we encounter any problem.

    Many thanks for all your efforts!

    Hila
  • Hi Hila,

    Thanks for your feedback.
    Do you recommend that we move to the new DLL as production version?

    No, instead we strongly recommend to use the official release version V5.02i of J-Link SDK.

    I will trigger a notification mail containing the download links.

    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.