Not sure if you've got anywhere with this - I'd seen the same thing with memory increasing and eventually KStars crashes mid-imaging. In summary, RPi 4 4GB, + astroberry, Canon DSLR, AZEQ6 & ZWO 120mm guidecam.
Tracked things down, by several simulation tests, wrote shell scripts to output memory usage and noted the cache seems to fill up, and eventually starts using Swap memory.
By updating the script to watch out for the cache and available memory, and if it gets too full, then things get purged automatically.
Memory usage keeps rising, but the script keeps purging, so I'm hoping I have found a workaround rather than solution.
shows my extensive tests, and scripts also so you could try and see if you got same result/success?
Post back so we can see!
before to check if we are getting any memory leaks, but I couldn't find anything substantial. Valgrind doesn't work at all with KStars, so we can't use that to figure out any memory leaks. Peter, you think you can use Heaptrack or another tool to help us pin this issue down?
For whatever it is worth, on a build from source not on an Astoberry distribution (last version I loaded) Kstars 3.5.7, Ian's method to show issue
"1. backup and then rm -r ~/.local/share/kstars ~/.indi ~/.config/kstarsrc for a fresh start
2. launch KStars
3. launch Ekos
4. wizard local devices -> create profile -> add simulator telescope and CCD
5. start Ekos
6. go to guider tab -> loop
7. Check RES memory usage via htop, check again every few minutes and notice a steady increase
I see no issues whatsoever after running for hours. I tried changing the main sim ccd resolution and using that as the guide capture also and still no growth.
This is on Pi with - 1gig- memory and buster
Linux pi-4-1 5.10.63-v7l+
This is actually a known issue and you can see in various places that notifications on non-KDE systems should be disabled due to some memory leak. I filed a bug report a couple of years ago with KDE (it's an old issue) but I don't think it was ever resolved.
So in my alternative post, Nou had commented about a message I'd seen in the log file (and dismissed!) about a
phonon error or warning
. I'd seen it in the SGL post and as mentioned, ignored it for now.
Seeing Nou's comment, I'd disabled the SOUNDS only but instead wrote warnings to a text file so I'd be able to see warnings or track them back.
Just started another simulation with ALL notifications OFF, and also disabled the "low resources" mode - it looks like my memory usage is more stable, although that's only after a short period. I'll leave it running and come back with another report later.
There was also another update released recently for lots of Indi updates, so if the issue is fixed, it could have been either - I'll test again later with notifications back on and see what happens.
Nope, still seeing memory usage increase with notifications on or off.
I'm not sure how to run heaptrack. It's installed, but not a great linux user to do have to either ask for a how-to crash course, sorry folks.
This was my experience as well - I delved waaaay into the rabbit hole when I was having this problem and found the "turn notifications and sounds off" potential solution (there are a number of threads on this, with this proposed solution), and it didn't seem to matter.
I recall actively being excited like "oh nice an easy solution" and of course it couldn't be that simple haha
@Nou, sorry if my terminology is incorrect. Just assumed memory leak is when memory is used up continuously, until the system has used all resources and causes things to crash. Let's not get bogged down with terminology!
As in my original
, I've had several sessions crash shortly after going to bed, and believe them to be from a lack of memory on the RPi.
I say this as I've documented the memory usage fill up, then the kstars logfile stops writing (kstars crashes) and the available memory increases and remains steady until I return to offload the imaging data several hours later.
Since really delving deeper (all the different memories, and purging the caches, etc), I've been unable to make it crash again, and as the nights are so short imaging isn't worth it just at present.
Again, I have a 'fix' that should work for me, but I'm disappointed that I've not been able to find the reason and solve the problem, but it does seem like there are others still seeing the same, perhaps without crashes...