Does SSDR 2.4.9 fix the memory leak reported 5 months ago?

  • 1
  • Question
  • Updated 3 weeks ago
  • (Edited)
Does anyone know if the memory leak (issue #6245) has been addressed in the latest version of SSDR?
I would rather not install it just to find out. The risk of adding any of the recently reported problems doesn't appeal.

https://community.flexradio.com/flexr...

Many thanks.
Photo of Paul

Paul

  • 456 Posts
  • 138 Reply Likes
  • curious

Posted 3 weeks ago

  • 1
Photo of James Whiteway

James Whiteway

  • 900 Posts
  • 219 Reply Likes
Paul,
I haven't experienced the memory leak issue with this release. Other than what I have posted here elsewhere in this forum, v2.4.9 has been working fine.
I would suggest looking at the release notes and history associated with this release to see if there has been any specific notes regarding the memory leak and its resolution, if any.
James
WD5GWY
Photo of Paul

Paul

  • 456 Posts
  • 138 Reply Likes
Thanks James. I did check release notes and SSDR change log but couldn't see it. I was wondering if it might be one of the often mentioned (but non-specific) "under the hood" improvements.
(Edited)
Photo of Lawrence Gray

Lawrence Gray

  • 115 Posts
  • 29 Reply Likes
I may be looking at the wrong measurement?  I was curious after reading this post, so I brought up the Resource Monitor and watched SmartSDR memory stat's.  Memory usage appears to continuously increase at a slow rate.  If I then connect with  PC B, disconnecting PC A, and then reconnect with PC A, the memory usage in PC A jumped about 20K.  Regardless of connects/disconnects, the memory usage appears to slowly increase over time.  I had just one DAX channel enabled and DAX TX enabled, no DAX IQ.  Running SSDR 2.4.9, Win7x64 Enterprise.  


Photo of Lawrence Gray

Lawrence Gray

  • 115 Posts
  • 29 Reply Likes
I setup Performance Monitor to graph SSDR memory usage over time.  A graph of SSDR process private bytes (red) and virtual bytes (green) usage of less than an hour run time is shown below.  It appears that memory use just continues to slowly increase over time.  You can also see a "bump" when I disconnected the monitored PC, connected with another PC and then reconnected the monitored PC.  

I'm just going to leave it running and see what happens.


Photo of Paul

Paul

  • 456 Posts
  • 138 Reply Likes
Interesting Laurence. It sounds like you are experiencing the same phemonenon that I highlighted in my original post. Very possibly Flex have not yet addressed the issue. Hopefully your extra metrics will help focus their attention.
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 2911 Posts
  • 632 Reply Likes
I wonder if you guys remember this from Tim 4 months ago?

 Tim - W4TME, Customer Experience Manager

  • 9149 Posts
  •  
  •  3468 Reply Likes






There are many under the covers performance enhancements in v2.2.8.  You should upgrade to benefit from those enhancements.

The issue #6245 describes a situation that when the SmartSDR-Win client is disconnected by another GUI client, SmartSDR-Win does not release all the objects and their associated memory.  If SmartSDR-Win then connects to another radio, a new set of objects are created, allocating additional memory.

If the time between the user disconnects is several minutes, the GC (garbage collection runs and some of the allocated memory is returned for use.

In order to create memory exhaustion condition, you have to do this back and forth of disconnecting SmartSDR from a radio and then reconnecting several times (in my test case with 4gb RAM it takes close 30-40 iterations, but that is dependent on how long you let SSDR-Win run between disconnects).  Because this memory condition is immediately mitigated by shutting down SmartSDR for Windows (it releases all the allocated memory and this back and forth disconnecting clients in fairly rapid succession does not constitute a 80/20 use case, therefore the issue was not deemed critical. 



So yes, it is a defect and we never said it wasn't, it is just not classified as critical.  As best we can tell the issue has existed for several years and was not notice or reported as a problem until recently.
Photo of Lawrence Gray

Lawrence Gray

  • 115 Posts
  • 29 Reply Likes
I do not read everything posted on this forum, so I missed the earlier discussion of this issue.  I saw the subject line of the current post in my email, read it, and was curious.  I checked the SSDR memory usage at my station because I was curious.  I noticed that memory usage continuously increased at a slow rate, even with no changes in the SSDR settings.  I then checked the connect/disconnect issue and found that, in fact, memory usage does increase and stays increased--garbage collection apparently does not return the memory.   This morning I happened to change profiles and noticed a step increase in memory usage, which was also not returned by the application.

A user posted an question.  I was curious and checked it out in my installation.  I found that, in fact, the condition still exists and that profile changes also can cause step increases in memory usage, which also does not appear to be returned by the application.   

So, the defect still exists.  Whether or not it is critical is entirely dependent on the use case.  For most users, including me, it would likely never be noticed.   However, memory leaks are fundamental flaws in application coding that should not be tolerated.  I assume someone is working on the issue and that it will be solved.  I can't say I understand the apparently angry/defensive post.  A user just asked a question about an issue that apparently does affect his particular use of the product.  Seems entirely reasonable that the user would have some expectation of the issue being corrected?

Larry, W1IZZ
Photo of K2CB Eric Dobrowansky

K2CB Eric Dobrowansky

  • 211 Posts
  • 80 Reply Likes
Yes, we do.

So has it been fixed?

And will it be fixed for those still running v1.x?
(Edited)
Photo of Paul

Paul

  • 456 Posts
  • 138 Reply Likes
Ditto thanks Eric.

Yes thank you Bill, as the OP I recall very clearly the comments made on behalf of Flex by Tim. Nothing in what they said implies that they will not fix this bug.

You may not remember (in the same thread) it transpired that, under some circumstances, the garbage collector didn't function as predicted. This led to SSDR hogging an ever increasing amount of memory and ultimately crashing.

Fortunately I have a VPN for remote operation & admin so I am able to periodically shut down the copy of SSDR in the shack before it crashes. My real concern is for those using Smartlink and whom may not have a VPN in place.

Additionally, IMHO this problem may become compounded when Flex gets round to delivering multi client. The number of repeated connect/disconnect cycles could then reach the critical point much quicker than now.

Bill, I hope you can now see my reasoning for asking this question. I do hope bug #6245 will be rectified before it becomes more prevalent. Given that Flex likes to tease us with the mention of "under the hood" fixes, I will remain curious and ask again until I read this has been cured.

73
(Edited)
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 2909 Posts
  • 631 Reply Likes
I think if it becomes an issue were it is effecting the radio performance they will not have a choice.
Photo of Lawrence Gray

Lawrence Gray

  • 115 Posts
  • 29 Reply Likes
It is an interesting issue.  Overnight, SSDR memory usage stabilized, as seen in the image below.  In the AM, I changed profiles to look at a different band/mode on the radio, which caused an step increase in memory usage at about 6:03.   Noting this change, I changed profiles 3 more times, causing the smaller steps at about 6:16.   I then disconnected and reconnected, causing the slightly larger step increase at about 6:19.

Currently at about 11 am, memory usage is 751 MB private memory and 1.2 GB virtual memory.   It does appear that there is a memory leak in the SSDR application.  It appears that eventually the application will run out of memory and crash.  The step increase with profile changes appears to indicate that profiles are held in application memory when no longer in active use?

As noted by others, there does seem to be an issue that needs to be resolved?



Larry, W1IZZ

Photo of Bill -VA3WTB

Bill -VA3WTB

  • 2894 Posts
  • 626 Reply Likes
If we were to read Tims reasons to why this happens we can understand what is going on. The reason it has not been corrected is that it has not effected the radio performance to date. But It seems clear that if and when It does they will move the problem to the front of the line for sure.
To worry about how our radios will be effected with the features to come is only speculation on our part because none of us really know.
(Edited)
Photo of Paul

Paul

  • 456 Posts
  • 138 Reply Likes
Thank you Laurence for your additional information. Perhaps as Bill mentioned, Flex might give this a higher priority as time goes on. I seem to recall someone suggested that a "forced garbage collection" is possible. Perhaps that might be a relatively simple solution to this bug. I do think though, that leaving a memory leak unchecked is not a good policy. Surely Bill, looking ahead and trying to predict potential areas of weakness is part of an efficient design process. Rather than waiting until things do become critical and then fighting the fire.
(Edited)