×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Read More...

KStars memory leak and crash

  • Posts: 9
  • Thank you received: 0

KStars memory leak and crash was created by Ian

I recently updated all packages to the latest (available through astroberry) versions kstars-bleeding 3.5.5-1/libindi11.9.2-1. It's been a few months since I've updated (checking apt history: 3.4.3 -> 3.5.0 in January, 3.5.0 -> 3.5.2 in May, 3.5.2 -> 3.5.5 recently). Please let me know if there's any more info I can provide/debugging steps that would help.

I've noticed that the memory consumption of KStars slowly climbs throughout the night while imaging. Last night when checking on the mount just before the meridian flip was scheduled to start, I noticed KStars was closed while the mount was still tracking. Launching KStars notifies me that indi is running in the background and prompts to close the process to launch a fresh one. After launching KStars again, I set up a quick script to log memory usage to disk every 1m and noticed KStars steadily increased over the night from ~300MB to ~900MB reserved memory (no crash this time). Second highest memory usage was python (don't remember which script) @ ~60MB. In journalctl I see:
Dec 02 21:31:25 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:31:26 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:31:28 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:31:29 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:31:30 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:31:31 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:31:31 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:31:31 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:31:32 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:31:33 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:31:35 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:31:36 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:31:37 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd

repeatedly throughout the night. usb 2-2 is the ASI120MM-S, and from what I can tell this is "normal" behavior. The swig/python memory leak stands out however. Looking at the python processes running I see:
- /usr/bin/indi-mqtt.py
- /var/www/astropanel/astropanel.py
- /var/www/gpspanel/gpspanel.py
- /var/www/indiwebmanager/main.py
- /usr/bin/virtualgps.py

and it looks like the mqtt and web manager both talk with indi, maybe they're involved/triggering the leak somehow?

Backtrace (probably not helpful since it just crashed due to OOM):
Core was generated by `kstars'.
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.
[Current thread is 1 (Thread 0xa3e81080 (LWP 1793))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0xb37ba230 in __GI_abort () at abort.c:79
#2  0xb380a50c in __libc_message (action=action@entry=do_abort, fmt=<optimized out>wink at ../sysdeps/posix/libc_fatal.c:181                                                                                           
#3  0xb3811034 in malloc_printerr (str=<optimized out>wink at malloc.c:5341
#4  0xb3812e50 in _int_free (av=<optimized out>, p=0x7e7c1b20, have_lock=0) at malloc.c:4258
#5  0xb55db970 in QVector<float>::reallocData(int, int, QFlags<QArrayData::AllocationOption>wink () from /usr/lib/arm-linux-gnueabihf/libstellarsolver.so.1                                                            
#6  0xb55e3288 in InternalSextractorSolver::extractPartition(InternalSextractorSolver::ImageParams const&wink () from /usr/lib/arm-linux-gnueabihf/libstellarsolver.so.1                                               
#7  0xb55ea5b0 in non-virtual thunk to QtConcurrent::RunFunctionTask<QList<FITSImage::Star> >::run() () from /usr/lib/arm-linux-gnueabihf/libstellarsolver.so.1                                                     
#8  0xb414df30 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#9  0xb4156b58 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#10 0xb4f06494 in start_thread (arg=0xa3e81080) at pthread_create.c:486
#11 0xb387a568 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6                                                                                                        
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

journalctl of crash (started KStars ~7:30pm, crashed ~9:54pm):
Dec 02 21:52:25 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:52:26 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:52:28 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:52:28 astroberry kernel: usb 2-2: WARN: Max Exit Latency too large
Dec 02 21:52:28 astroberry kernel: usb 2-2: Could not enable U2 link state, xHCI error -22.
Dec 02 21:52:28 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:52:28 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:52:28 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:52:29 astroberry kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 02 21:52:30 astroberry systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Dec 02 21:52:30 astroberry systemd[1]: Started Process Core Dump (PID 5473/UID 0).
Dec 02 21:53:10 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:53:11 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:53:11 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:53:52 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:53:52 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:53:52 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:53:58 astroberry systemd-coredump[5474]: Process 1782 (kstars) of user 1001 dumped core.
                                                   
                                                  Stack trace of thread 1793:
                                                  #0  0x00000000b37cef14 __GI_raise (libc.so.6)
                                                  #1  0x00000000b37ba230 __GI_abort (libc.so.6)
                                                  #2  0x00000000b380a50c __libc_message (libc.so.6)
                                                  #3  0x00000000b3811034 malloc_printerr (libc.so.6)
                                                  #4  0x00000000b3812e50 _int_free (libc.so.6)
                                                  #5  0x00000000b55db970 _ZN7QVectorIfE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE (libstellarsolver.so.1)
Dec 02 21:53:59 astroberry systemd[1]: systemd-coredump@0-5473-0.service: Succeeded.
Dec 02 21:54:34 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:54:34 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:54:34 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:55:15 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:55:15 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:55:15 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:55:57 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:55:57 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:55:57 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:56:40 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:56:40 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:56:40 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:57:22 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:57:22 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:57:22 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:58:03 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:58:03 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:58:03 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.
Dec 02 21:58:45 astroberry python3[1047]: swig/python detected a memory leak of type 'INDI::BaseDevice:cheekyroperties *', no destructor found.

swig/python messages continue to print after kstars crashed, I'm assuming because indi is still running in the background.

Setup:
- Raspberry Pi 4 Model B/2GB running Astroberry
- ZWO ASI120MM-S (indi_asi_ccd)
- Sky-Watcher EQ6-R Pro (indi_eqmod_telescope)
- Olympus O-MD E-M10 Mark II (external intervalometer, not connected to Pi)

Imaging process:
- Go-to target
- Align -> Slew to target
- Adjust manually
- Align -> Sync
- Mount -> meridian flip @ 0.5h (scheduled to flip ~12am), HA limit 1.5h, park @ 4:10am
- Guide via EQMod Mount
- Start external intervalometer
 
Last edit: 2 years 4 months ago by Ian.
2 years 4 months ago #78289
The topic has been locked.
  • Posts: 3
  • Thank you received: 0

Replied by Jonathan on topic KStars memory leak and crash

Ian, I had the identical scenario last night. My crash appeared to be around the meridian flip period too but I was noticing a gradual memory leak building up on my RPi 4 (4gb) until when it gets to around 50% of available is when it seem to crash. Between targets I even restarted it to try and avoid issues but this morning I awoke to find everything running, except KStars of course, so imaging seemed to stop around the time I was expecting the meridian flip (about 20 mins after I went to bed on a fantastic clear & good seeing night - it was watching me lol).
I do not use the fits viewer once imaging as I have seen similar in the previous versions cause this same issue.

My setup is similar (but different)
IOptron CEM60
ASI 2600mm and guide ASI174mm mini with ASI EFW.
All runs on Astroberry...

My workflow is very similar to yours

I did notice memory increasing when focusing (anecdotal of course)

Did not have this issue with prior version, ran all night no issues, no memory incremental over time, only since upgrading to 3.5.5 which I now wish I hadn't...
Anyone know how to downgrade without losing all my carefully honed settings?

All verbose logging is now on to try and isolate when it exactly happens.

Jonathan
2 years 4 months ago #78316
The topic has been locked.
  • Posts: 9
  • Thank you received: 0

Replied by Ian on topic KStars memory leak and crash

Jonathan, that's interesting. Sounds like it might be the same cause.

I was able to image last night without crashing, with KStars ending up at ~1GB reserved memory in the morning. I left Ekos on the Analyze tab, you're probably on to something with the tab being relevant. I think I left it on the Guiding tab last time, I'll try that tonight.

Downgrading might be possible if the packages are still in the apt cache, but I would be worried about settings not being compatible with older versions.
2 years 4 months ago #78326
The topic has been locked.
  • 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 4 months ago #78401
The topic has been locked.
  • Posts: 104
  • Thank you received: 21

Replied by Grimaldi on topic KStars memory leak and crash

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 4 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 4 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 1 month 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 1 month 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 1 month ago #81139
The topic has been locked.
  • Posts: 20
  • Thank you received: 0

Replied by Germán on topic KStars memory leak and crash

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 10 months ago #83322
The topic has been locked.
  • Posts: 19
  • Thank you received: 1

Replied by Pete Simpson on topic KStars memory leak and crash

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 10 months ago #83470
The topic has been locked.

Replied by Jasem Mutlaq on topic KStars memory leak and crash

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 10 months ago #83480
The topic has been locked.
Time to create page: 0.682 seconds