Dear Segger,
We have encountered an issue with the JLinkARM DLL that when the JLINKARM_Close function is called it appears to leave some allocated memory.
We use the JLinkARM DLL in a manufacturing environment, the main application runs under National Instruments TestStand, we have developed a C# DLL to interface between TestStand and the JLinkARM DLL. The C# DLL uses the method LoadLibrary & FreeLibrary, this is so we can use specific versions of the JLinkARM DLL depending on the product being manufactured. We have done this to allow us to try newer versions of the JLinkARM DLL with certain products/micros, but keep existing production untouched until we have verified the latest DLL will not caused any issues with production. The C# DLL is loaded & disposed of each time a individual product is tested from the main TestStand application, this could happen hundreds of times during a production shift. We found that since trying to deploy a newer version of the JLinkARM DLL version 7.98i this memory leak issues has been present. The previous version we have used v7.88k does not have the same issue. From testing various versions it appears v7.96 was when this problem was introduced. I have also tested with the latest version received with the SDK v8.12a and the issue appears to still be present.
In saying all of this, as I understand Segger would prefer to only support issues for application written in C and C++, I have managed to replicate this possible memory leak issue in JLinkARM DLL using a simple C utility, taking some of the sample Segger source code and modifying them to replicate the issue I am seeing from our C# DLL.
I’ve created two utilities, one to use a static linked JLinkARM DLL (JLinkARM_StaticLoadTester) and the other to dynamically load the JLinkARM DLL (JLinkARM_DynamicLoadTester), source code attached. The dynamically load the JLinkARM DLL utility can show that after 50 cycles of loading/using/unloading the JLinkARM DLL v8.12a that over 200K of memory has been allocated, where as the same process with JLinkARM DLL v7.88k only 23K of memory has been allocated.
Note: I have not shown the results of the static loaded JLinkARM DLL testing as this method does not cause any possible memory leak.
We would appreciate someone from Segger looking into this issue as this is stopping us moving to the latest JLinkARM DLL in our production environment, something that we will soon require due to newer micros being used on our products.
Here are the results of running the dynamically loaded JLinkARM DLL version 8.12a:
Memory allocation before starting the test cycles
Utility output
Memory allocation after completion
Here are the results of running the dynamically loaded JLinkARM DLL version 7.88k:
Memory allocation before starting the test cycles
Utility output
Memory allocation after completion
We have encountered an issue with the JLinkARM DLL that when the JLINKARM_Close function is called it appears to leave some allocated memory.
We use the JLinkARM DLL in a manufacturing environment, the main application runs under National Instruments TestStand, we have developed a C# DLL to interface between TestStand and the JLinkARM DLL. The C# DLL uses the method LoadLibrary & FreeLibrary, this is so we can use specific versions of the JLinkARM DLL depending on the product being manufactured. We have done this to allow us to try newer versions of the JLinkARM DLL with certain products/micros, but keep existing production untouched until we have verified the latest DLL will not caused any issues with production. The C# DLL is loaded & disposed of each time a individual product is tested from the main TestStand application, this could happen hundreds of times during a production shift. We found that since trying to deploy a newer version of the JLinkARM DLL version 7.98i this memory leak issues has been present. The previous version we have used v7.88k does not have the same issue. From testing various versions it appears v7.96 was when this problem was introduced. I have also tested with the latest version received with the SDK v8.12a and the issue appears to still be present.
In saying all of this, as I understand Segger would prefer to only support issues for application written in C and C++, I have managed to replicate this possible memory leak issue in JLinkARM DLL using a simple C utility, taking some of the sample Segger source code and modifying them to replicate the issue I am seeing from our C# DLL.
I’ve created two utilities, one to use a static linked JLinkARM DLL (JLinkARM_StaticLoadTester) and the other to dynamically load the JLinkARM DLL (JLinkARM_DynamicLoadTester), source code attached. The dynamically load the JLinkARM DLL utility can show that after 50 cycles of loading/using/unloading the JLinkARM DLL v8.12a that over 200K of memory has been allocated, where as the same process with JLinkARM DLL v7.88k only 23K of memory has been allocated.
Note: I have not shown the results of the static loaded JLinkARM DLL testing as this method does not cause any possible memory leak.
We would appreciate someone from Segger looking into this issue as this is stopping us moving to the latest JLinkARM DLL in our production environment, something that we will soon require due to newer micros being used on our products.
Here are the results of running the dynamically loaded JLinkARM DLL version 8.12a:
Memory allocation before starting the test cycles
Utility output
Memory allocation after completion
Here are the results of running the dynamically loaded JLinkARM DLL version 7.88k:
Memory allocation before starting the test cycles
Utility output
Memory allocation after completion