Chiming in here since I have the same problem and it's extremely frustrating and from what I can determine, completely random
This manifests in my Kstars logs as the following immediately before Kstars completely crashes:
[2022-04-07T11:50:33.885 EDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/home/astroberry/Pictures/astro_test/4-6-22_crash_investigation/Light/L/Light_L_40_secs_2022-04-07T11-50-33_018.fits"
[2022-04-07T11:50:33.885 EDT DEBG ][ org.kde.kstars.fits] - Reading file buffer ( "116.7 MiB" )
[2022-04-07T11:50:35.028 EDT INFO ][ org.kde.kstars.ekos.capture] - "Download Time: 2.33 s, New Download Time Estimate: 2.42 s."
[2022-04-07T11:50:36.871 EDT INFO ][ org.kde.kstars.ekos.capture] - "Received image 14 out of 80."
[2022-04-07T11:50:39.217 EDT DEBG ][ org.kde.kstars.fits] - Removing 12 stars from HFR calculation
[2022-04-07T11:50:39.217 EDT INFO ][ org.kde.kstars.ekos.capture] - "Captured /home/astroberry/Pictures/astro_test/4-6-22_crash_investigation/Light/L/Light_L_40_secs_2022-04-07T11-50-33_018.fits"
[2022-04-07T11:50:41.013 EDT DEBG ][ org.kde.kstars.fits] - FITS HFR: 0.655716
[2022-04-07T11:50:41.694 EDT INFO ][ org.kde.kstars.ekos.capture] - "Capturing 40.000-second L image..."
[2022-04-07T11:51:21.751 EDT INFO ][ org.kde.kstars.indi] - QHY CCD QHY600M-6e29e74 : "[INFO] Exposure done, downloading image... "
[2022-04-07T11:51:29.058 EDT WARN ][ default] - QObject::~QObject: Timers cannot be stopped from another thread
What I'm doing each time for this at this point is I have an Ekos capture sequence of 80 light frames, 40sec exposure, then I just run that until it inevitably dies - sometimes 2 images into the sequence, sometimes 18, sometimes it will get through the entire sequence with no issues - today happens to be a crash-happy day, so it's good for debugging.
Tried also doing super verbose logging in Ekos for literally everything possible, but the above is the only thing I get unfortunately - I also tried disabling all sounds as per
another thread
but that merely removed some additional warnings regarding QObjects; didn't stop the crash.
Used gdb to attach to kstars as well since that is a good idea I didn't think of, and get the following:
//These are successful saved images before the crash
INDI::BaseClient::connectServer: creating new connection...
[New Thread 0x937a3040 (LWP 2579)]
INDI::BaseClient::connectServer: Already connected.
[Thread 0x9a980040 (LWP 2508) exited]
[New Thread 0x9a980040 (LWP 2581)]
[Thread 0x9a980040 (LWP 2581) exited]
Found one coordinate representation.
[New Thread 0x9a980040 (LWP 2600)]
[Thread 0x9a980040 (LWP 2600) exited]
Found one coordinate representation.
[New Thread 0x9a980040 (LWP 2619)]
[Thread 0x9a980040 (LWP 2619) exited]
Found one coordinate representation.
[New Thread 0x9a980040 (LWP 2636)]
[Thread 0x9a980040 (LWP 2636) exited]
Found one coordinate representation.
[New Thread 0x9a980040 (LWP 2655)]
[Thread 0x9a980040 (LWP 2655) exited]
/home/astroberry/DEV/BUILD/indi/libs/lilxml.c(moremem): Failed to allocate memory.
Thread 1 "kstars" received signal SIGSEGV, Segmentation fault.
0xb4258044 in QMutex::lock() () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
(gdb) backtrace
#0 0xb4258044 in QMutex::lock() () at /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#1 0xb494c66c in () at /usr/lib/arm-linux-gnueabihf/libQt5Gui.so.5
Interestingly, due to using an older Pi4 with 2GB of RAM (I thought it was running out of memory and legitimately may have been), I discovered that the vast majority of RAM was utilized by the FITS viewer and summary preview screen in the EKOS "General" section, but didn't want to image without being able to see what was going on.
So I actually set up Kstars on my Windows machine to connect to the Pi4 remotely so I could do the FITS viewer processing somewhere else, and only utilized the INDI server on the Pi4 to allow Kstars to connect to it. Once I figured out bandwidth issues (large images hang in downloading and driver restarts without good transfer speeds), offloading the FITS rendering to my desktop negated any crashes that I can tell (I need to run this again with a very large number of exposures to really test it).
Topic Author
