Memory Leak

knro wrote: I would like to know how I can replicate this.. I took 500 images on StellarMate a couple of weeks ago and I couldn't detect any memory leak. Was HIPS overlay enabled? I'd like to replicate exact conditions.

Thanks knro, next time I create a log, HIPS is disabled.
I forgot to mention that they are all FITS image ( fits viewer is disabled ).

knro wrote: I would like to know how I can replicate this.. I took 500 images on StellarMate a couple of weeks ago and I couldn't detect any memory leak. Was HIPS overlay enabled? I'd like to replicate exact conditions.

If HIPS overlay is enabled by default then yes, it is. My objective is to be able to pack the whole imaging train minus the mount into a suitcase, preferably carry-on sized bag. Resolving this is very important to me since I'm trying to avoid taking a full computer into the field. Full control and imaging from a RPi opens SO many possibilities that I really want to explore.

I was wondering, for the folks with the memory leak--do you have the option "Single Preview Tab" checked? (I think you should have it checked).
You find that under the KStars options, then FITS, then it's a checkbox on that page.
I believe that KStars/fitsviewer would leak tabs if you had it unchecked (perhaps it should limit the number of tabs, I don't know if it does or doesn't).
Hy

hy wrote: I was wondering, for the folks with the memory leak--do you have the option "Single Preview Tab" checked? (I think you should have it checked).
You find that under the KStars options, then FITS, then it's a checkbox on that page.
I believe that KStars/fitsviewer would leak tabs if you had it unchecked (perhaps it should limit the number of tabs, I don't know if it does or doesn't).
Hy

hy wrote: I was wondering, for the folks with the memory leak--do you have the option "Single Preview Tab" checked? (I think you should have it checked).
You find that under the KStars options, then FITS, then it's a checkbox on that page.
I believe that KStars/fitsviewer would leak tabs if you had it unchecked (perhaps it should limit the number of tabs, I don't know if it does or doesn't).
Hy

I was about to make the same comment. That box needs to be checked to prevent consecutive tabs from opening.
In addition, I always leave my FITS viewer minimized. I also use an SSD with swap enabled, that might also make a difference.
I had the memory overflow a couple of times, but only when I ran KStars from a microSD card. Unsure how to explain that, though.

Sounds strange, but I can apparently duplicate the memory leak with those options disabled. Using Canon T6s, Astroberry over VNC. I duplicated with upload to client set. After a few images, I get the "Unsufficient Memory" errors.

I did some testing with the CCD Simulator (with the same frame size as the Canon) and did not notice a memory leak, even looping to the FITS viewer.

hy wrote: I was wondering, for the folks with the memory leak--do you have the option "Single Preview Tab" checked? (I think you should have it checked).
You find that under the KStars options, then FITS, then it's a checkbox on that page.
I believe that KStars/fitsviewer would leak tabs if you had it unchecked (perhaps it should limit the number of tabs, I don't know if it does or doesn't).
Hy

I was about to make the same comment. That box needs to be checked to prevent consecutive tabs from opening.
In addition, I always leave my FITS viewer minimized. I also use an SSD with swap enabled, that might also make a difference.
I had the memory overflow a couple of times, but only when I ran KStars from a microSD card. Unsure how to explain that, though.

I should have kept my big mouth shut! I did not have these out of memory problems for a long time - until last night.
I had made no changes to my configuration from the night before, when the system performed flawlessly and collected over 300 frames. Last night it ran out of memory after 113. I woke up to the message on the desktop that there was not enough free memory to report the cause of the crash. KStars had shut down.
I have no clue what is causing this, but I did not change any of the parameters I had highlighted earlier. And as I said, the system performed great the night before, no changes made, no updates, nothing....

I have just confirmed that after disabling FITS previews there is no memory leak. You can go hundreds of frames with no problem whatsoever.
The workaround to the memory leak is to disable:
- fits viewer (Settings / Configure KStars / FITS / Use FITS Viewer) and
- preview on main Ekos tab (Settings / Configure KStars / Ekos / Capture / Summary Screen Preview)

Indeed, those two settings do the magic - but this is probably not just about getting memory filled as this happens even with a handful of captured frames.
This is very disappointing, I finally bit the bullet and upgraded my KStars to the latest and this is now practically unusable the way it is.

Also, brief rundown on how to reproduce the problem:

- Using simulator devices: CCD sim, telescope sim, guider sim
- Created a new sequence (3x lum, 3x red) and saved it
- Opened the scheduler, chose M 34 (I doubt this matters), selected the sequence
- Did not touch the sequence conditions
- Add and run the sequence

A crash will most likely occur at some point (had one happen at 2 frames, one happen at 3 frames, etc).
I doubt this is even exactly a simple memory leak since it happens so quickly, and my machine has 8GB of RAM, a pair of simulator camera frames hardly make a dent.
As said, disabling those two options act as a workaround, so this is definitely FITS viewer related.

Attached a verbose log.
The crash happens right after "Reading FITS file buffer".

I tried the bug reporting tool but unfortunately it failed to get anything useful out of it, so I tried running it with gdb, and that perhaps gave out something useful:

The WCS crash is not a memory leak issue, but thread synchronization issue that I thought we resolved already. At any rate, I just pushed memory-related fixes in the hope that it improves the situation. Can everyone please compile from GIT and report back?

I suspected as much - when did the thread sync issue get fixed, which commit hash? It is present in the current release, 3.3.9 (Build 2020-01-02T08:17:38Z).
I did try to re-produce that yesterday from the latest sources but failed, so it does seem like it has been fixed (can't be 100% sure since I was testing on another computer) but I can't exactly find which commit did that.