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

Yes indeed Eric, I just enabled all the logs to find the culprit of this, but as I progress with my bug hunt I'll surely clear up the logs from unnecessary data.
Thanks for having a look at it!

Try create new profile with your devices reproduce crash and then remove them one by one. Like EAF, power box ASI290, EQ6.

I have similar gear as you (have a ASI1600MM-Pro not a GT and have a different focuser), I might see if I can try this. I also run Manjaro ARM rather than Astroberry/StellerMate or Ubuntu based, though I could try to burn an image something default. I can also try to run a test from my x86_64 server. I'll let you know how this goes.