I tend to get crashes when using internal solver. Try opening the options on the alignment page, and select "Local astrometry" for the solver instead of "internal solver". You may need to run "sudo apt-get install astrometry.net" from a terminal, if it isn't installed already.

It will use the same index files you've already installed.

Thank you Kevin! I'll try that as well indeed. Last night happened again twice while doing load and slew from the alignment panel, same mmap error which leads to SIGSEGV and brutal death of KStars..funny thing is that it always dies on the same file: 4107.fits. I think this is a mere coincidence, but it's something that notheless I've noticed. A friend of mine also suggested to try increasing the swap, which by default is 100Mb, to 2-4Gb or increase the max_map_count value, that is by default 65536, with the command:
I guess I'll try to make changes one by one until I get things stable on my Raspberry. At least now I'm certain that the responsible is the solver and is memory related, I just need to know how to replicate it predictably.
By the way I'm running the latest software from PPA, so I should be all up-to-date.
Thanks again Kevin!

So unchecking this doesn't help? It can be found in Align module options.
 

Hey Nou, unfortunately it didn't help..it's the first thing I tried, but surprisingly crashed at the first solve I did :/
I can't seem to be able to replicate it using the simulator, my theory is that the simulator solves immediately without the need to scale down to lower FOVs index files, that would also explain why it always crashes at 4107.fit, which should be 22'x30' of the Thyco Catalog.
Another user seems to have experienced the same issue , but he wasn't able to fix it.
Thank you guys for trying to help here, beside this issue which can be even dangerous when it's doing the meridian flip and I'm sleeping hoping that everything goes ok, everything else works really well!
Hope to sort it out, would be a shame to not be able to use the Ekos-KStars solution for my astrophotography.

Hey Marco,

Do you know if you're using a 32bit or 64 bit Linux? I've not kept up to date with Astroberry but I know that I had issues with Astroberry and using a 32 bit o/s. I've got a lot better stability of the system using a 64 bit Linux but I use a my own setup using ArchLinux and not the Astroberry or StellarMate that most people use. However, you can find that most people tend to get better stability if it's a 64bit OS.

Hey Will,
lscpu returns armv7l, so I believe it should be 32bit (I'm running astroberry on a PI4 8Gb and waiting for the 64bit update since Raspbian it's still in beta..)
However I'll post the lines before the system crashed of last night session.

If you use Load&Slew, does it crash? If yes, post a link to the FITS image causing this.

FWIW, I use Raspbian 64-bit, and have better stability than I did on 32-bit. I build 64-bit INDI and KStars from source. There might be 64-bit ARM .deb packages somewhere, I don't know, I haven't looked.

That being said, I still had a crash or two using the internal solver, so I switched to using an external one, and those problems went away.
 

Hi Jasem!
Yes, when I was preparing the session on the Crescent yesterday and I ran load and slew to recenter the target from the previous night, it crashed during solving.
This is the FIT file , I attach the log as well in case it could be useful.

That solved in 2.87 seconds in StellarMate and GOTO worked as expected without any issues. So it must be something else that is causing the crash and not memory (have 4GB on SM)

Thank you Jasem for taking the time to test it!
This doesn't happen for me either if I use the simulator, however it happens "in production" with my gears.
I have the following setup:
- SW EQ6 Pro
- ASI 1600 GT (same as 1600 MM but with EFW incorporated SBIG-like)
- ASI 290 MM mini for guiding
- ASI EAF Motor
- Pegasus Power Box Advance

I run everything on the Raspberry to which I connect using VNC via browser or alternatively TeamViewer if I'm away from home.
Did you also have a look at the log file? Any suggestion on how I can try to get more informations on what's going on? I'll try to run KStars with gdb tonight, let's hope it will give me a more descriptive output of the hard crash.
Anyway thanks again for your time, I really appreciate it!

There's a huge amount of eqmod serial communication in the logs. If the mount is out of the equation and that level of detail is not needed, it may help the Pi to disable debug logs for that device.

-Eric