Does SSDR v2.2.8 fix the memory leak previously reported?

  • 2
  • Question
  • Updated 4 months ago
  • (Edited)
Does anyone know if the memory leak issue #6245 has been addressed in the latest version of SSDR?

https://community.flexradio.com/flexr...
Photo of Paul

Paul

  • 434 Posts
  • 127 Reply Likes

Posted 4 months ago

  • 2
Photo of Jim Runge

Jim Runge

  • 78 Posts
  • 15 Reply Likes
Mine starts off at 115 MB and continues to climb. After 10 hours it is up to 232 MB.
Photo of Wayne

Wayne

  • 614 Posts
  • 84 Reply Likes
Interesting I never have mine on for more than a couple of hours at a time and since I operate stand alone 6400M I never noticed a memory issue.
Photo of Paul

Paul

  • 434 Posts
  • 127 Reply Likes
Hi Wayne. My original report related to SSDR for Windows and the issue was then only apparent under the specific circumstances described;

when two clients take turns to operate the radio. Before it can connect, client A must disconnect client B (and vice versa). The issue occurs only if the disconnected client is left running at the connect screen (ie. not closed down after disconnection). Memory is then not released on the disconnected client and each subsequent connect/disconnect ramps up the memory usage until SSDR crashes.

Closing SSDR does release the memory, so if this is done before usage reaches a critical level, the issue will not be apparent. I do not know if M models exhibit the same behaviour.
(Edited)
Photo of Paul

Paul

  • 434 Posts
  • 127 Reply Likes
Any input from Flex on this question?
Photo of Michael Walker

Michael Walker, Employee

  • 268 Posts
  • 75 Reply Likes
Your memory increase is likely the Waterfall history storage.  It does have a high water mark and is based on the number of panadapters, and width displayed.   

This is normal operation.  

Mike
Photo of Jim Runge

Jim Runge

  • 78 Posts
  • 15 Reply Likes
Thanks Mike.
Photo of Paul

Paul

  • 434 Posts
  • 127 Reply Likes
Sorry Mike but this has already been acknowledged by Tim, in my original post, as a bug (issue #6245 as per the title of this post).

I was simply enquiring if it had been fixed in the latest version. Surely you are not implying that it's normal for the waterfall history to use up memory to the point where SSDR crashes? Or perhaps you were just replying to Jim?
(Edited)
Photo of Mike - VE3CKO

Mike - VE3CKO, Elmer

  • 350 Posts
  • 133 Reply Likes
I did not see that particular issue listed in the SmartSDR v2.2.8 Change Log (scroll down to Change Log), so it would safe to say, no, the memory leak issue #6245 you referred to did not get addressed.
Photo of Michael Walker

Michael Walker, Employee

  • 268 Posts
  • 75 Reply Likes
Yes, I was on the phone with Tim when I wrote it.  It is not a leak.  The memory is consumed by the waterfall history.  It will not drive SSDR to crash or consume all memory.  I ran 2.2.8 for 6 days on my 6600 while I was at Dayton and I got to about 320MB.  If I remember correctly it was about 150mb when I started it.  This was on a fully patched Windows 10.

Are you seeing this in 2.2.8?

Mike
Photo of Paul

Paul

  • 434 Posts
  • 127 Reply Likes
Mike (VE3CKO) - thanks for your suggestion. I did look there but given the long list of items, I wanted to confirm that I had not overlooked it.
(Edited)
Photo of Paul

Paul

  • 434 Posts
  • 127 Reply Likes
Michael, a couple of points:

1) the problem occurs when SSDR is disconnected from the radio so I do not see how the waterfall, which is not then running, can consume further memory. Unless, of course SDDR does not release that memory when the radio is disconnected. In which case there IS a bug, regardless of whether you want to call a memory leak or not. The issue was reproduced independently by Rick. My understanding was that Tim had documented it as described under #6245 - but maybe not if he now says it's not a problem.

2) Your diagnosis would certainly apply to the symptoms described by Jim though.

3) Not withstanding 2), I would like to emphasise that Jim's symptoms and those I reported ARE NOT the same. I suggest that if there is confusion at FLEX about this, someone should review carefully my original report:

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

4) I have not tried the latest version. I am waiting until a fix is included before doing so; SSDR is otherwise stable here, and I do not wish to disrupt it for purely cosmetic changes. I will happily update to whatever version does contain a fix.

73, Paul
(Edited)
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9148 Posts
  • 3467 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 Paul

Paul

  • 434 Posts
  • 127 Reply Likes
Thanks for clarifying the definition of the defect Tim. I believe I misunderstood Michael's comment. I can see now from your description why it has not been allocated a high priority. It's good to know that it will eventually be addressed. 73.
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9148 Posts
  • 3467 Reply Likes
As can be seen from the changelog, defect #6245 was not included in v2.2.8.