INDI Library v1.9.7 Released (29 Jul 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

QObject Crashes Ekos Several Times per Night

  • Posts: 4
  • Thank you received: 0
I have been struggling with this issue ever since upgrading to the latest version of Astroberry with new Kstars/Ekos/PHD2. Looking through the logs, it mostly seems to happen immediately after Download complete, but the file is not present where it is expected, I just get this error as the last entry in the logs:
[2022-01-08T03:41:09.947 EST WARN ][                       default] - QObject::~QObject: Timers cannot be stopped from another thread

Sounds are all disabled, I did get similar errors in the past that seemed related to Phonon issue, but I have disabled sounds for all notifications.

I would run the ekos debugger, but I haven't found instructions for how to get that installed and compiled on astroberry, when I try to install using sudo apt-get install ekos-debugger, there is nothing to install.

Attached the most recent crash log, hoping someone can help me get past this.

7 months 2 days ago #79208

Please Log in or Create an account to join the conversation.

  • Posts: 175
  • Thank you received: 38
ekos-debugger is AFAIK just script to run kstars under normal gdb. So you can try run it manually. Run "gdb kstars" from terminal. Then press r enter to start kstars from debugger. When it crash you can use "backtrace" command to get stack so we know where it does crash.
7 months 2 days ago #79212

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 2
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).
Last edit: 4 months 3 days ago by MH. Reason: Kstars, not EKOS
4 months 3 days ago #82110

Please Log in or Create an account to join the conversation.

  • Posts: 105
  • Thank you received: 9
I get this problem as well using a ZWO ASI2600MM Pro and had it for some time despite running on a 8gb Pi 4 and updating/re-installing astroberry, changing cables and power supplies. Very infuriating especially as it is unpredictable. I do hope the developers have this bug as top priority because it makes the system unusable. I have read reports of a couple of possible solutions:

Try disabling sounds for messages in Kstars settings. It got rid of the last warning messages in the log relating to QT GUI which I think the QObject ones relate to. However this didn't fix the problem for me. Kstars still crashes.
Disable the FITS viewer. I am reluctant to do this as I use it! Not tested this workaround yet.

Yesterday I took about 150 calibration bias images during the day without a crash! Last night I started Light imaging and it kept crashing after one or two images! I suspect the problem may relate to using the imaging camera for alignment and/or focussing before imaging. My hunch is resources are not cleaned up between EKOS modules say going from focussing to imaging bearing in mind the user can prematurely stop focussing and alignment before they complete which I have to do sometimes.
4 months 2 days ago #82137

Please Log in or Create an account to join the conversation.

Time to create page: 0.795 seconds