×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

KStars memory leak and crash

  • Posts: 9
  • Thank you received: 0

Replied by Ian on topic KStars memory leak and crash

Update: I didn't end up imaging, however yesterday I tested a few cases:

1. Leaving KStars open without starting Ekos: no memory increase
2. Leaving KStars open with Ekos started, mount parked, guiding set to "loop": slow memory increase from 205MB to 355MB from 8:50AM to 10:50AM (1.25MB/min). No log messages about swig/python.
3. Building master (e7bc2c83c6d2975e049019d2b01fd16ff4e45625), stable-3.5.2, and 3.5.0 from source and repeating #2: same behavior.

This makes it seem like either a. it's not KStars, maybe an indi/astroberry issue or b. it's KStars, and either been around for a while or there's always been a slow leak and occasionally there's a larger leak that leads to the crash I experienced or c. it's KStars, and a recent indi/astroberry change has exposed an underlying issue.

Additonally, when closing KStars after #2 /usr/bin/indi_eqmod_telescope crashed. Looking back this happened twice on Dec 2nd as well. Not sure if it's related. Journalctl:
ec 05 10:50:13 astroberry systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Dec 05 10:50:13 astroberry systemd[1]: Started Process Core Dump (PID 20598/UID 0).
Dec 05 10:50:13 astroberry systemd-coredump[20599]: Process 17270 (indi_eqmod_tele) of user 1001 dumped core.                                                                                                      
 
                                                    Stack trace of thread 17270:
                                                    #0  0x00000000b63faf14 __GI_raise (libc.so.6)
                                                    #1  0x00000000b63e6230 __GI_abort (libc.so.6)
                                                    #2  0x00000000b66408d8 _ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6)                                                                           
Dec 05 10:50:13 astroberry systemd[1]: systemd-coredump@0-20598-0.service: Succeeded.

Core dump:
Core was generated by `indi_eqmod_telescope'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0xb63e6230 in __GI_abort () at abort.c:79
#2  0xb66408d8 in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#3  0xb663e5b0 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#4  0xb663d56c in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
2 years 3 months ago #78401
The topic has been locked.
  • Posts: 104
  • Thank you received: 21
As are running Astroberry, all of the python processes you report at the top are panels that are available from left hand pop-out menu in the web interface (when you open Astroberry.local in the browser). You can take all of them out of the equation by

sudo systemctl stop <…>.service
sudo systemctl disable <…>.service

See /etc/systemd/system/*.service
2 years 3 months ago #78438
The topic has been locked.
  • Posts: 9
  • Thank you received: 0

Replied by Ian on topic KStars memory leak and crash

Good idea. I've tested by
sudo systemctl stop astropanel.service indiwebmanager.service indi-mqtt.service
and verifying the processes stopped. Unfortunately, still seeing a leak.

Additionally, I built KStars and libindi from master on my x86_64 desktop and attempted to reproduce the memory leak without luck. Also built the 3.5.5 KStars and 1.9.2 libindi tags (versions astroberry is using), no dice.

Simple repro on astroberry:
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

It doesn't appear to matter which tab it's left on. I've tested switching to the Scheduler tab in case it was due to images/charts updating but it still leaks.
2 years 3 months ago #78448
The topic has been locked.
  • Posts: 18
  • Thank you received: 2

Replied by MH on topic KStars memory leak and crash

I've seen the same behavior time and time again with my Pi4, was wondering if it was just me or something else was going on...

I haven't yet been able to get it to actually crash outright, but still notice the steady RAM utilization increases overnight; usually by morning the system is using 80%+ of available RAM, and the syslog output just has a ton of messages in the format of:
astroberry python3[1109]: swig/python detected a memory leak of type 'INDI::BaseDevice::Properties *', no destructor found.
2 years 3 weeks ago #81135
The topic has been locked.
  • Posts: 18
  • Thank you received: 2

Replied by MH on topic KStars memory leak and crash

I've seen the same behavior time and time again with my Pi4, was wondering if it was just me or something else was going on...

I haven't yet been able to get it to actually crash outright, but still notice the steady RAM utilization increases overnight; usually by morning the system is using 80%+ of available RAM, and the syslog output just has a ton of messages in the format of:

<code>swig/python detected a memory leak of type 'INDI BaseDevice Properties *', no destructor found</code>

(had to change the actual formatting of the syslog message so it would actually post; that's not the exact format but is the exact verbiage)
2 years 3 weeks ago #81138
The topic has been locked.
  • Posts: 18
  • Thank you received: 2

Replied by MH on topic KStars memory leak and crash

I've seen the same behavior time and time again with my Pi4, was wondering if it was just me or something else was going on...

I haven't yet been able to get it to actually crash outright, but still notice the steady RAM utilization increases overnight; usually by morning the system is using 80%+ of available RAM, and the syslog output just has a ton of messages in the format of:
swig/python detected a memory leak of type 'INDI BaseDevice Properties *', no destructor found

(had to change the actual formatting of the syslog message so it would actually post; that's not the exact format but is the exact verbiage)
2 years 3 weeks ago #81139
The topic has been locked.
  • Posts: 20
  • Thank you received: 0
Hi folks,

I have got the same problem the swig/python detected a memory leak:

astroberry python3[2015]: swig/python detected a memory leak of type 'INDI::BaseDevice::Properties *', no destructor found.

Do you have some solutions for that? I have got many craash session when I use the Scheduler.

Please I need your help.

Thank you so much and best regards. Germán.
1 year 9 months ago #83322
The topic has been locked.
  • Posts: 19
  • Thank you received: 1
German,
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.
My post here 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!
1 year 9 months ago #83470
The topic has been locked.
I've used Heaptrack 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?
1 year 9 months ago #83480
The topic has been locked.
  • Posts: 155
  • Thank you received: 12
I am trying to use the sanitizers on kstars to see what gets thrown out. Threw out a number of complaints but not yet sure whether they are actual leaks or not. Still investigating.
1 year 9 months ago #83487
The topic has been locked.
  • Posts: 276
  • Thank you received: 52

Replied by Gene N on topic KStars memory leak and crash

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
Quote
"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+
1 year 9 months ago #83513
The topic has been locked.
  • Posts: 276
  • Thank you received: 52

Replied by Gene N on topic KStars memory leak and crash

Disable all Pulseaudio and notifications?
I ran the same on an Astroberry with Kstars 3.5.5 and it gobbled up memory.

Disabled the service as above, still growing
Stopped NGIX service and still growing.

Disabled pulsaudio and all Notifications and -STOPPED- growing.

After an hour:

====================================
top - 12:35:52 up 2:01, 3 users, load average: 0.51, 0.41, 0.54
Tasks: 198 total, 3 running, 195 sleeping, 0 stopped, 0 zombie
%Cpu(s): 9.3 us, 4.4 sy, 0.0 ni, 85.3 id, 0.1 wa, 0.0 hi, 0.9 si, 0.0 st
MiB Mem : 459.7 total, 49.0 free, 213.4 used, 197.3 buff/cache
MiB Swap: 512.0 total, 277.2 free, 234.8 used. 181.3 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27888 root 20 0 638280 184280 90568 R 34.7 39.1 0:55.56 kstars
27947 root 20 0 70380 12016 8544 R 6.9 2.6 0:01.98 indi_simu+
27614 root 20 0 0 0 0 I 5.3 0.0 0:06.31 kworker/u+
570 root 20 0 229664 33880 17792 S 4.3 7.2 4:12.68 Xorg

top - 13:40:28 up 3:06, 3 users, load average: 0.71, 0.63, 0.64
Tasks: 195 total, 1 running, 194 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8.5 us, 3.3 sy, 0.0 ni, 88.1 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
MiB Mem : 459.7 total, 38.6 free, 211.2 used, 209.9 buff/cache
MiB Swap: 512.0 total, 280.2 free, 231.8 used. 179.2 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27888 root 20 0 638280 184296 90568 S 34.7 39.2 18:46.90 kstars
27947 root 20 0 70380 12128 8608 S 8.3 2.6 4:48.05 indi_simu+

With Pulseaudio/Notifications running:
top - 11:16:12 up 41 min, 3 users, load average: 1.78, 1.30, 0.86
Tasks: 204 total, 3 running, 201 sleeping, 0 stopped, 0 zombie
%Cpu(s): 12.4 us, 6.6 sy, 0.0 ni, 80.2 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st
MiB Mem : 459.7 total, 42.7 free, 249.7 used, 167.3 buff/cache
MiB Swap: 512.0 total, 317.0 free, 195.0 used. 132.6 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1929 root 20 0 766644 171056 59476 S 34.1 36.3 5:14.50 kstars
1985 root 20 0 70248 11584 8196 S 9.3 2.5 1:02.27 indi_simu+

astroberry@astroberry:~ $ top
top - 12:13:20 up 1:38, 3 users, load average: 0.29, 0.53, 0.71
Tasks: 198 total, 2 running, 196 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8.6 us, 4.1 sy, 0.0 ni, 87.1 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
MiB Mem : 459.7 total, 31.4 free, 294.2 used, 134.1 buff/cache
MiB Swap: 512.0 total, 296.0 free, 216.0 used. 90.5 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1929 root 20 0 923868 216068 43748 S 31.1 45.9 24:20.27 kstars
1985 root 20 0 70248 7532 4844 S 7.9 1.6 5:15.49 indi_simu
1 year 9 months ago #83542
The topic has been locked.
Time to create page: 1.116 seconds