can't solve, crashing
Hy Murveit
murveit at gmail.com
Tue Dec 15 03:21:02 GMT 2020
to continue yesterday's saga,
I restarted the same job tonight (under gdb).
I noticed that the target position is in the trees--so it should have
difficulty solving etc.
scheduler starts up,
it slews (to a point that's mostly obscured, as I said)
it manages to focus properly anyway, using stars that come through the
trees.
it crashes in align.
Below is the stdout/err including the (uninformative) gdb backtrace,
and the log is here:
https://drive.google.com/file/d/1RbOZP9UB-u_5d-tuiSVUSSnC7LCIkQSI/view?usp=sharing
[EDIT: FWIW, I re-tried with an object that is not obscured, and got the
same failure--perhaps this is related to my 8Gb RPi4? E.g. StellarSolver
thinks it has more memory to play with than it really has?]
I wish I knew how to find out what is allocating so much memory that malloc
fails.
[New Thread 0xa101a0a0 (LWP 18837)]
[Thread 0xa101a0a0 (LWP 18837) exited]
Found one coordinate representation.
[New Thread 0xa101a0a0 (LWP 18857)]
[New Thread 0x8fd590a0 (LWP 18858)]
TAN-SIP Structure:
crval=(79.7863, 33.766)
crpix=(1185.67, 224.415)
CD = ( -0.0010881 0.00016994 )
( -0.00016994 -0.0010881 )
image size = (1552 x 1173)
SIP order: A=2, B=2, AP=2, BP=2
A = 0 0 0
0 0
0
B = 0 0 0
0 0
0
AP = 0 0 0
0 0
0
BP = 0 0 0
0 0
0
sqrt(det(CD))=3.9646 [arcsec]
TAN-SIP Structure:
crval=(80.3947, 33.4387)
crpix=(776.5, 587)
CD = ( -0.0010897 0.00016478 )
( -0.00016379 -0.0010902 )
image size = (1552 x 1173)
SIP order: A=2, B=2, AP=2, BP=2
A = 0 0 2.0552e-07
0 -3.6796e-07
2.0958e-07
B = 0 0 1.8151e-07
0 1.9834e-07
-6.3042e-07
AP = -4.3387e-08 -1.2113e-07 -2.0552e-07
1.523e-07 3.6796e-07
-2.0958e-07
BP = -4.7244e-09 9.1297e-08 -1.8151e-07
-1.776e-07 -1.9834e-07
6.3042e-07
sqrt(det(CD))=3.96813 [arcsec]
[Thread 0xa101a0a0 (LWP 18857) exited]
Found one coordinate representation.
[New Thread 0xa101a0a0 (LWP 19067)]
[New Thread 0x8f5580a0 (LWP 19072)]
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Thread 54 "QThread" received signal SIGABRT, Aborted.
[Switching to Thread 0x8fd590a0 (LWP 18858)]
__GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0 0xb38d1f24 in __GI_raise (sig=sig at entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1 0xb38bd230 in __GI_abort () at abort.c:79
#2 0xb3b178d8 in __gnu_cxx::__verbose_terminate_handler() () at
/lib/arm-linux-gnueabihf/libstdc++.so.6
#3 0xb3b155b0 in () at /lib/arm-linux-gnueabihf/libstdc++.so.6
#4 0xb3b15624 in () at /lib/arm-linux-gnueabihf/libstdc++.so.6
#5 0xb422ca18 in qt_assert(char const*, char const*, int) () at
/lib/arm-linux-gnueabihf/libQt5Core.so.5
#6 0xb4259ce0 in () at /lib/arm-linux-gnueabihf/libQt5Core.so.5
#7 0xb5009494 in start_thread (arg=0x8fd590a0) at pthread_create.c:486
#8 0xb397d578 in () at ../sysdeps/unix/sysv/linux/arm/clone.S:73
On Mon, Dec 14, 2020 at 12:49 AM Hy Murveit <murveit at gmail.com> wrote:
> I got my system working, though I'm not sure of all what happened.
> Here's a partial debrief.
>
> Something happened that caused align to fail, and possibly to crash with
> the bad_alloc early in the evening.
> Don't know what that was. When that happened, my telescope was left
> pointing at my target--not at the north star.
> I restarted kstars and tried to get align working...but I forgot to reset
> the scope.
> From then on, when I was debugging and trying to get my system working
> again, my scope
> had the wrong idea about where it was pointing, and so the "use position"
> constraint in alignment caused it to fail,
> and me to debug in vain.
>
> Once I actually went outside and looked at the scope, I realized I should
> disable "use position" and ASTAP worked.
> Then I purged the park position, and got the scope and kstars/indi back on
> track.
> I actually got one more bad_malloc from StellarSolver's internal solver,
> but I don't have the energy to figure out
> if there's still an issue with that. I'm just going to image with ASTAP
> tonight, and worry about it some other day.
>
> Hy
>
>
> On Sun, Dec 13, 2020 at 11:38 PM Hy Murveit <murveit at gmail.com> wrote:
>
>> Don't know what's up tonight, but cannot solve at all, and sometimes
>> crash.
>> Here's a log with a std::bad_alloc on the stderr and a crash
>>
>>
>> https://drive.google.com/file/d/1nR3r7Tijjj9HIJuUxvbTXngLobAbo-Md/view?usp=sharing
>>
>> The end of the log has values that look corrupted
>>
>> [2020-12-13T23:29:39.139 PST INFO ][ org.kde.kstars.ekos.align] -
>> "codetol -2.71764e-51"
>> [2020-12-13T23:29:39.174 PST INFO ][ org.kde.kstars.ekos.align] -
>> "startdepth 60"
>> [2020-12-13T23:29:39.209 PST INFO ][ org.kde.kstars.ekos.align] -
>> "enddepth 70"
>> [2020-12-13T23:29:39.244 PST INFO ][ org.kde.kstars.ekos.align] -
>> "fieldunits_lower -2.71764e-51"
>> [2020-12-13T23:29:39.279 PST INFO ][ org.kde.kstars.ekos.align] -
>> "fieldunits_upper -2.71764e-51"
>> [2020-12-13T23:29:39.316 PST INFO ][ org.kde.kstars.ekos.align] -
>> "verify_pix -2.71764e-51"
>> [2020-12-13T23:29:39.352 PST INFO ][ org.kde.kstars.ekos.align] -
>> "xcolname X"
>> [2020-12-13T23:29:39.388 PST INFO ][ org.kde.kstars.ekos.align] -
>> "ycolname Y"
>> [2020-12-13T23:29:39.423 PST INFO ][ org.kde.kstars.ekos.align] -
>> "maxquads 0"
>> [2020-12-13T23:29:39.458 PST INFO ][ org.kde.kstars.ekos.align] -
>> "maxmatches 0"
>> [2020-12-13T23:29:39.493 PST INFO ][ org.kde.kstars.ekos.align] -
>> "cpulimit -0.000000"
>> [2020-12-13T23:29:39.529 PST INFO ][ org.kde.kstars.ekos.align] -
>> "timelimit 600"
>> [2020-12-13T23:29:39.564 PST INFO ][ org.kde.kstars.ekos.align] -
>> "total_timelimit -2.71764e-51"
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201214/f5fa8884/attachment.htm>
More information about the Kstars-devel
mailing list