Just compiled the latest indi and kstars (3.3.6-787_gcefa36d91).
Trying to run a short exposure (0.01s) reproducibly crashes kstars (though I was able to take one exposure before).

I restarted in gdb and made a backtrace, seems FITS/histogram related?

Hmm, that must be something different. I downgraded both kstars and indi, but it still crashes. Could that be kernel related? Or some other lib? Just also had done a system update....

I think I can really nail it down on the FITS viewer. I can do basically anything - align, focus, stream video, capture sequences (with FITS viewer disabled). Click on Preview and - BOOOM.

The crazy thing is, I've reverted to older (working) RPMs. I've even booted into (previously working) snapshots, both on the laptop and on the mount computer. Sometimes it works for a few images, but sooner or later (rather sooner) it crashes.

Is there anything in the kstars config related to the viewer? Because my config/home directory is the only thing that was always the same.

(This really sucks, seeing is absolutely great, the mount tracks at <0.3" - and the camera crashes permanently (( )

Unfortunately, I cannot reproduce this even with latest builds.

Yes, I was afraid so
Would you have any guides how to further investigate? gdb tricks? It must be something secondary that triggers the crash, else it wouldn't do so with versions that ran fine before. At least it seems I can run as long as I don't use the FITS Viewer itself. The inline versions in the overview, focus and align tabs are not triggering a crash, only the 'standalone/external' one.

Just a quick hit and run thought here. Try removing your XML files and replacing with defaults. When you downgrade the XML's keep you old settings. Hope it helps. That sucks bad on a good night. Been there...cried on Jasem's shoulder more than once.

Thanks for the comforting. Yes, I'd been thinking of moving the config etc. away, but doing that in the middle of the night also has a good chance forgetting some setting when coming from scratch, and messing up things there So I rather went on without using the FITS viewer.
I'll surely keep it in mind for the next time!
(But of course, next day at daylight it would just run again, without any crash.....)

So, after it had been running without problems for a while, today it permanently starts crashing again.

But I got one step further, I can nail it down to the FITS file. The last entry in the kstars logfile always is that it is loading a FITS file from /tmp.
And I checked, that file stays there when kstars crashes.

And guess what, If I just start kstars, select 'Open FITS' and try to load this file - crash.
So I've now made that file available here (32MB).

Would be nice to know if that file also crashes other peoples FITS viewer, and/or maybe some knowledgeable person can use it to debug the issue?

I tried it with my working edition of Kstars (from 080819) and it opened okay. It was all white though. Hitting it with autostretch in the viewer showed some banding and stuff.

Then I tried to open it in my VM that has nearly the latest compile and it crashed to desktop with this error reported to dmesg:
``` kstars[2233] trap divide error ip:55de0d2813b3 sp:7ffdcc62a590 error:0 in kstars[55de0c771000+ff7000]```
Then I opened one of my fits files with Kstars fit viewer and it was fine.

You should file an issue at Kstars and be sure to include that file. I suspect it could have something to do with it being saturated and for some reason quite large.
Also, try opening kstars and loading an another file you know will open in another app.

This is was fixed in KStars yesterday. The nightly should have the fix and if you compile from GIT it should work as well. The histogram was crashing in some over saturated files.

Yes, I had seen the other message/thread, but only after posting the file here
It indeed used to crash mostly when reducing exposure time to counter overexposure (daylight/skyflats).
Interestingly, completely saturated files seemed not a problem.

Time well spent.