It's raining here and I decided to investigate the KStars "memory leak" issue with a stress test. I noticed that if I close the FITS Viewer window during an imaging session the RAM is not released on the RPi4. The result is that the memory allocated to KStars grows. Being bored and retired I decided to take this to the limit. I created a dummy imaging session with 100, 10 s subs and I closed the FITS viewer each time the image downloaded. As I expected, the RAM allocated to KStars grew from 912 MB to about 3000 MB at which time (I assume) swapping into VM starts to occur. I continued this process and observed the RAM allocation staying the same but the allocation of VM continues to grow. The system began to get very sluggish and when the VM allocation reached 6.1 GB, KStars crashed (probably because the RPi is trying to save itself). The control experiment where I don't close the FITS viewer results in a stable system with no memory allocation increase. The obvious solution to this issue is - don't close the FITS viewer window -but maybe this observation can be used to help locate a bug. I am using the latest Stellarmate version 1.8.0.

I also have this issue with my Odroid N2+ and kstars 3.6.7 and can confirm the behavior.

Thank you for the detailed report. I was trying to reproduce this issue for *several* years. If indeed closing the FITS Viewer is what leads to this, then it is at least reproducible and we can take a closer look.

I’m glad to be of help. The other place where I have experienced a KStars crash is in the alignment module. I can appreciate that this module is very demanding on resources so a crash here is not necessarily related to the module itself, but if KStars has maxed out the RAM allocation and then you try to run Alignment then you could get into trouble. The other night when this was about to happen I noticed that the RAM allocation was at 3000 MB. I had been doing quite a bit of imaging, and as is my habit, closing the FITS Viewer window, plus aligning at several points. So I am not sure exactly sure what caused the crash, just that I was using the Alignment module when it happened. I will devise another experiment using the simulator to see if I can replicate the issue with the Alignment module by itself.

I just finished this latest experiment. I set up a profile with my mount and the telescope simulator and did a series of alignments on Vega. As before, the RAM allocation for KStars crept up by about 100 MB per alignment run. However, in this case the maximum RAM allocation was 2300 MB at which point VM swapping seemed to start, dropping the allocation to a steady 2100 MB. I quit the experiment after 20 alignment operations. There was no crash in this experiment and no detectable degradation in performance.

Then I decide to try to provoke a crash by taking images as before and closing the FITS Viewer each time. The RAM allocation mounted to just over 3000 MB. Then I moved back to the alignment module and did a few alignment runs. Eventually the program slowed to a halt, stuck in the alignment module. No crash, but as good as. This is consistent with what I observed the other night in my real imaging run.

One more observation. If I do the multiple FITS Viewer window closure routine but do not provoke a crash, after closing all windows except for the main KStars window, the RAM allocation for KStars falls to 782 MB. However, the total RAM used remains at 3100 MB. It does not get released until KStars is closed. I hope all of this is of use to you.

Jasem, I’m no C++ programmer but I was browsing the FITSViewer code on GitHub and I might have found something. At line 312 of FITSViewer.cpp you are defining the destructor but there is no code within the following parentheses as there is in the destructor definition in FITSview.cpp.
Mike

No that destructor is OK and I tried your experiment but I couldn't detect any major leaks. But can you try the following? add buffer.clear(); to lines 873 and 878 in indicamera.cpp as you see in the attachment then recompile. Does this make any difference?

Yikes! You are giving me too much credit as this is beyond my capacity. I find it odd that you can’t reproduce the problem. Is this the way we have configured our respective systems? Just you have all the info, I am running Stellarmate from a 1TB SSD that I partitioned 64GB for the OS, and the rest for the Astrometrics folder and Picture Folder. There is about 40GB free on the 64GB partition. I am using a ZWO ASI294MC Binning 1. There is simply no doubt that here the RAM allocation reaches 3100 MB after which performance is severely degraded.

I was able to reproduce your memory leak. I sent Jasem an MR for his review which I believe fixes it.
See invent.kde.org/education/kstars/-/merge_requests/1069

All that said, it seems like a minor issue--at least the one associated with my fix.
You lose memory when you kill FITS Viewers, which should be corrected by my MR, but as you point out
it is unusual to kill a bunch of FITS Viewers.

Hy

Thanks, Hy. Don’t get me wrong, i think what you all have been doing with KStars over the past two decades is absolutely fabulous. It is encouraging that people across the planet can cooperate to achieve something so wonderful.

Thanks for fixing that “memory leak” bug, Hy and Jasem. I downloaded the latest code today and it is releasing the memory. Now all I need is a clear night and to re-collimate after a particularly chilly night.