My last three clear nights have been cut short while I slept by what appear to be random crashes of KStars 3.5.4 on ubuntu 20.04.2 LTS (miniPC not Pi).

I know that there's a bunch of detective work that's possible for random crashes, involving running in the debugger and analyzing logs.

I also know that my crashes don't involve the FITS viewer, which I've disabled.

Maybe I will embark on the detective game, but wow. This is dispiriting. Everything appears to be running really well and then out of nowhere POW. No more KStars.

I wake up in the morning with all the equipment on and the mount tracking and nobody home to collect the data. Over and over.

Ugh.

Hello Scott,
I know the feeling.
I have the same version running on Raspberry PI/Astroberry. In my last session, I had it twice, each time involving the FITS viewer, once when clicking the histogram icon and once when just bringing it to the front.
I could not find any thing relevant in /var/log/messages or other log files in /var/log
I run on a PI with 8GB memory, so lack of memory shouldn't be the problem.
Next time I'll activate the debug logging, but looking at the weather report, that will not be for any time soon
g.

I've had the same problems with 3.5.4 since the upgrade. I've been running KStars under the EKOS Debugger, but it doesn't seem to be catching the problem. I'm beginning to think the upgrade changed something in Linux/INDI environment that the debugger doesn't see.

Mine has crashed on the initial start of a sequence, right after the slew to the object. It has also crashed right during the meridian flip, right after the slew. It has also crashed after parking the mount. All seem to be associated with whatever happens immediately after slewing... but I'm not an expert.

I will continue to try as I get some clear nights... But I will have to revert to 3.5.3 if it doesn't clear up soon.

Good luck!

Ron

Sorry about the frustrating crashes.

Can you try running kstars using Jasem's ekosdebugger to give us more clues?
See for instance:
indilib.org/forum/ekos/7245-new-tool-ekos-debugger.html

If you don't want to go that route, or have difficulty installing it,
you can often get a backtrace for random crashes by running kstars inside of gdb debugger.
To do that you need to know the path to your kstars binary, e.g. run
      which kstars
on the command line. It will likely return "/usr/bin/kstars" on linux.
If you're running a special version you compiled, then of course use that binary location.
Then, instead of starting kstars your usual way, you start it with the command-line
     gdb /usr/bin/kstars 
(or replace /usr/bin/kstars with whatever you're using)
and when you get the gdb prompt "(gdb)", type:
    run
that should start kstars.
If kstars crashes, you'll be left in the gdb prompt, or sometimes a line like "--type <RET> for more, ..." to which you hit a carriage-return.
then, back in the gdb prompt, you type 
    bt
to get a backtrace of where it was when it crashed. 
Cut and paste the backtrace, I guess along with your log.
You can then exit gdb with 
    quit
However, it's simpler to just use ekosdebugger.

Thanks,
Hy

Hy,

Thanks for the follow-up. I've also been working with Jasem on this problem. I ran KStars under the EKOS Debugger when it crashed after parking, but the log didn't show anything after successfully parking the mount. Also, the entire RPi locked up afterwards. So... we weren't successful in capturing the problem.

When I get a clear night, I will try again. However, I'm leaving on a trip for a few weeks and won't likely get something to you in the near term. Hopefully, the other guys can trap the error.

Thanks!

Ron

Great to hear that you (and possibly others) are working with Jasem on this. Obviously he's the one that knows best.

If it's any consolation, I too had a crash last week, and was able to trace the issue. That one's now fixed in the beta software.
See invent.kde.org/education/kstars/-/merge_requests/387
It was related to an interaction between Capture, StellarSolver and guiding,
when guiding happens to abort (e.g. due to clouds) just after a captured image is downloaded.