Hi,

reporting back after a long while - ran last night the same polar alignment scenario with the latest Kstars build (2020-08-08T19:57:56Z), and the polar alignment still crashes with Toupcam GPCMOS01200KPB on Pi3. Please see the gdb backtrace below. I've changed cables, power supplies, etc with no apparent effect. I'm just wondering could this still be somehow related to the Toupcam driver behaving differently from the Altair drivers, e.g. ? At least one difference in the logs between Altair camera and this Toupcam is notion "This looks like a multi-color image: processing the first image plane only. (NAXIS=3)" - could this affect e.g. memory usage in the associated processing? I'm under the impression that "apt-get update && apt-get upgrade" updates also the drivers in Indi so I suppose that I'm using the latest ones.. Is there some way to run some other diagnostics beyond what I've done so far?

Many thanks for your great work on Kstars, it really rocks!

-Harri



#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x739c7230 in __GI_abort () at abort.c:79
#2 0x73a1751c in __libc_message (action=<optimized out>, fmt=<optimized out>)
at ../sysdeps/posix/libc_fatal.c:181
#3 0x73a996fc in __GI___fortify_fail_abort (
need_backtrace=need_backtrace@entry=false,
msg=0x73ae052c "stack smashing detected") at fortify_fail.c:28
#4 0x73a996c0 in __stack_chk_fail () at stack_chk_fail.c:29
#5 0x0063e238 in FITSData::pixelToWCS (this=0x3fa4ce60,
this@entry=0x6863be80, wcsPixelPoint=..., wcsCoord=...)
at ./kstars/kstars/fitsviewer/fitsdata.cpp:1804
#6 0x0090036c in Ekos::Align::calculatePAHError (this=this@entry=0x405d1a0)
at ./kstars/kstars/ekos/align/align.cpp:5403
#7 0x009041ec in Ekos::Align::setWCSToggled (this=0x405d1a0,
result=<optimized out>) at ./kstars/kstars/ekos/align/align.cpp:5815
#8 0x74a3f380 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#9 0x006b73ac in FITSView::wcsToggled (this=this@entry=0x3c81138,
_t1=<optimized out>, _t1@entry=true)
at ./obj-arm-linux-gnueabihf/kstars/KStarsLib_autogen/GB6ZSSQLTO/moc_fitsview.cpp:343
#10 0x0062d700 in FITSView::syncWCSState (this=0x3c81138)
at ./kstars/kstars/fitsviewer/fitsview.cpp:1787
#11 0x006bd7d0 in FITSView::qt_static_metacall (_o=<optimized out>,
_c=<optimized out>, _id=<optimized out>, _a=<optimized out>)
at ./obj-arm-linux-gnueabihf/kstars/KStarsLib_autogen/GB6ZSSQLTO/moc_fitsview.cpp:220
#12 0x74a3f244 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#13 0x748667b8 in QFutureWatcherBase::event(QEvent*) ()
from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#14 0x75334db4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#15 0x7533d2a8 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#16 0x03c81154 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Read More...

Hi, here's the gdb backtrace, hope it helps!

#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x739c7230 in __GI_abort () at abort.c:79
#2 0x73a1751c in __libc_message (action=<optimized out>, fmt=<optimized out>)
at ../sysdeps/posix/libc_fatal.c:181
#3 0x73a996fc in __GI___fortify_fail_abort (
need_backtrace=need_backtrace@entry=false,
msg=0x73ae052c "stack smashing detected") at fortify_fail.c:28
#4 0x73a996c0 in __stack_chk_fail () at stack_chk_fail.c:29
#5 0x00635728 in FITSData::pixelToWCS (this=0x3fa01abc, this@entry=0x4d4a828,
wcsPixelPoint=..., wcsCoord=...)
at ./kstars/kstars/fitsviewer/fitsdata.cpp:1676
#6 0x008d80f8 in Ekos::Align::calculatePAHError (this=this@entry=0x417b1c8)
at ./kstars/kstars/ekos/align/align.cpp:5389
#7 0x008dbd5c in Ekos::Align::setWCSToggled (this=0x417b1c8,
result=<optimized out>) at ./kstars/kstars/ekos/align/align.cpp:5771
#8 0x74a3f380 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#9 0x0069b63c in FITSView::wcsToggled (this=this@entry=0x3e3bcc0,
_t1=<optimized out>, _t1@entry=true)
at ./obj-arm-linux-gnueabihf/kstars/KStarsLib_autogen/GB6ZSSQLTO/moc_fitsview.cpp:343
#10 0x00624990 in FITSView::syncWCSState (this=0x3e3bcc0)
at ./kstars/kstars/fitsviewer/fitsview.cpp:1635
#11 0x006a1884 in FITSView::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at ./obj-arm-linux-gnueabihf/kstars/KStarsLib_autogen/GB6ZSSQLTO/moc_fitsview.cpp:220
#12 0x74a3f244 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#13 0x748667b8 in QFutureWatcherBase::event(QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#14 0x75334db4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#15 0x7533d2a8 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#16 0x03e3bcdc in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Read More...

Hi,

just reporting back - tried this out with the latest build: 2020-04-13T21:01:23Z, the issue still persists:

[2020-04-24T22:43:04.154 EEST INFO ][ org.kde.kstars.ekos.align] - "Solver RA (262.54332) DEC (88.28288) Orientation (130.78559) Pixel Scale (15.23043)"
[2020-04-24T22:43:04.231 EEST INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (17h 16m 44s) DEC ( 88° 15' 41\") Telescope Coordinates: RA (21h 16m 19s) DEC ( 90° 00' 00\")"
[2020-04-24T22:43:04.271 EEST INFO ][ org.kde.kstars.ekos.align] - "Please wait while WCS data is processed..."
[2020-04-24T22:43:04.318 EEST INFO ][ org.kde.kstars.indi] - Toupcam GPCMOS01200KPB : "[INFO] CCD FOV rotation updated to 130.786 degrees. "
[2020-04-24T22:43:12.423 EEST INFO ][ org.kde.kstars.ekos.align] - "WCS data processing is complete."
[2020-04-24T22:43:12.584 EEST DEBG ][ org.kde.kstars.ekos.align] - P1 RA: "15h 55m 44s" DE: " 88° 46' 59\""
[2020-04-24T22:43:12.586 EEST DEBG ][ org.kde.kstars.ekos.align] - P2 RA: "16h 39m 57s" DE: " 88° 30' 16\""
[2020-04-24T22:43:12.587 EEST DEBG ][ org.kde.kstars.ekos.align] - P3 RA: "17h 30m 10s" DE: " 88° 16' 58\""
[2020-04-24T22:43:12.588 EEST DEBG ][ org.kde.kstars.ekos.align] - P1 X: 607.494 Y: 299.816
[2020-04-24T22:43:12.588 EEST DEBG ][ org.kde.kstars.ekos.align] - P2 X: 644.125 Y: 382.08
[2020-04-24T22:43:12.588 EEST DEBG ][ org.kde.kstars.ekos.align] - P3 X: 640 Y: 480
[2020-04-24T22:43:12.592 EEST DEBG ][ org.kde.kstars.ekos.align] - P1 CP X: 0 CP Y: 0
[2020-04-24T22:43:12.593 EEST DEBG ][ org.kde.kstars.ekos.align] - P2 CP X: 0 CP Y: 0
[2020-04-24T22:43:12.593 EEST DEBG ][ org.kde.kstars.ekos.align] - P3 CP X: 332.596 CP Y: 214.791

Read More...

Hi,

and sorry if this is discussed already somewhere else, tried to extensively search and read the previous forum posts on polar alignment crashing. I'm using latest build 2020-02-14T16:34:45Z but the problem persists with ToupCam GPCMOS01200KPB. I've been using Kstars with Raspberry Pi3 for some time now, and really love it as it makes the setup really portable. However, polar alignment with this camera is still causing trouble.

Had a chance to test the same setup with Altair GPCAMAR0130M camera (only the camera changed, everything else being exactly the same), and it works just fine, no crashing. Please see the logs for both Altair and ToupCam. Unfortunately as the ToupCam is an older version it cannot be used with Altair drivers so I'm stuck with this one.. I've been using the ToupCam camera for some time and pretty much everything else works just fine (guiding, etc.) so it would be really great if it could be used for polar alignment as well.

Any help would be greatly appreciated!

-Harri

File Attachment:

File Name: Toupcam_crash.txt
File Size: 55 KB

File Attachment:

File Name: Altair_success.txt
File Size: 41 KB


Read More...