KStars v3.5.0 Release Date?
Hy Murveit
murveit at gmail.com
Fri Oct 16 05:55:32 BST 2020
Core dump again with the 'load all indexes' flag unchecked. Am running in
gdb now.
...
Also, it doesn't seem to remember that checkmark, nor the profile type (top
menu under ""Options Profiles")--please add that to the todo list too.
Also, it's my impression that the solver takes longer than it used to.
Could it be that the binning isn't being honored?
Perhaps you derived your speed by threading, and I'm defeating that by
unchecking the box?
...
Here's the backtrace, as it crashed again--this time in GDB.
I guess I'm done testing for the night.
Hy
log-odds ratio 0.335153 (1.39815), 0 match, 0 conflict, 0 distractors, 39
index.
RA,Dec = (318.284,63.9039), pixel scale 3.84851 arcsec/pix.
log-odds ratio 0.335153 (1.39815), 0 match, 0 conflict, 0 distractors, 39
index.
RA,Dec = (318.284,63.9039), pixel scale 3.84851 arcsec/pix.
log-odds ratio 34.6274 (1.09262e+15), 18 match, 0 conflict, 120
distractors, 37 index.
RA,Dec = (325.282,58.0472), pixel scale 3.97646 arcsec/pix.
Hit/miss: Hit/miss:
----+-----------+--+--+------+---------------+---+------+----+--+--+---------------+-----------+----
[Thread 0x83925090 (LWP 1384) exited]
Thread 38 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x92c2c090 (LWP 31265)]
belong (corenb=corenb at entry=0, coreobjlist=coreobjlist at entry=0xb42b9afc
<debobjlist>, shellnb=shellnb at entry=0,
shellobjlist=0x47d6cbc) at
/home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:378
378 int xc=PLIST(cpl+cobj->firstpix,x),
yc=PLIST(cpl+cobj->firstpix,y);
(gdb) bt
#0 belong (corenb=corenb at entry=0, coreobjlist=coreobjlist at entry=0xb42b9afc
<debobjlist>,
shellnb=shellnb at entry=0, shellobjlist=0x47d6cbc)
at /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:378
#1 0xb4217178 in deblend (objlistin=0xa8cb2b00, objlistin at entry=0x92c2b1c4,
l=l at entry=0, objlistout=0x0,
objlistout at entry=0x92c2b0c4, deblend_nthresh=75328520,
deblend_nthresh at entry=0,
deblend_mincont=0.0050000000000000001, minarea=minarea at entry=5)
at /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:125
#2 0xb4217b4c in sortit (info=info at entry=0xa8cc52b0, objlist=0x92c2b1c4,
objlist at entry=0x92c2b1bc, minarea=5,
minarea at entry=2, finalobjlist=0xa8c296d8, finalobjlist at entry=0x0,
deblend_nthresh=32,
deblend_nthresh at entry=3, deblend_mincont=0.0050000000000000001, gain=1)
at /home/pi/Projects/stellarsolver/stellarsolver/sep/extract.c:777
#3 0xb4219e80 in sep_extract (image=0x5b8d6c
<NewFOV::slotDetectFromINDI()+324>, image at entry=0x8ecf2008,
thresh=thresh at entry=54.3094788, thresh_type=thresh_type at entry=1,
minarea=2, minarea at entry=5,
conv=0xa8cc7100, convw=<optimized out>, convw at entry=3, convh=convh at entry=3,
filter_type=<optimized out>,
filter_type at entry=0, deblend_nthresh=32,
deblend_cont=0.0050000000000000001, clean_flag=1, clean_param=1,
catalog=0x92c2b514, catalog at entry=0x92c2b50c)
at /home/pi/Projects/stellarsolver/stellarsolver/sep/extract.c:632
#4 0xb41edc34 in InternalSextractorSolver::runSEPSextractor
(this=this at entry=0xa8cb9e70)
at /usr/include/c++/8/cmath:475
#5 0xb41eed90 in InternalSextractorSolver::sextract (this=0xa8cb9e70)
at
/home/pi/Projects/stellarsolver/stellarsolver/internalsextractorsolver.cpp:94
#6 InternalSextractorSolver::run (this=0xa8cb9e70)
at
/home/pi/Projects/stellarsolver/stellarsolver/internalsextractorsolver.cpp:137
#7 0xb420ddd4 in StellarSolver::extract (this=0x9e403bd0,
calculateHFR=calculateHFR at entry=true, frame=...)
at /usr/include/c++/8/bits/atomic_base.h:390
#8 0x00c4c4c8 in FITSSEPDetector::findSourcesAndBackground
(this=0x92c2b89c, boundary=..., bg=bg at entry=0x0)
at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qrect.h:60
#9 0x00c4a32c in QtConcurrent::StoredMemberFunctionPointerCall2<bool,
FITSSEPDetector, QRect const&, QRect, SkyBackground*,
decltype(nullptr)>::runFunctor() (this=0x424be80)
at
/usr/include/arm-linux-gnueabihf/qt5/QtConcurrent/qtconcurrentstoredfunctioncall.h:911
#10 0x004df0f0 in QtConcurrent::RunFunctionTask<bool>::run (this=0x424be80)
at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmutex.h:240
#11 0xb4855f30 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#12 0xb485eb58 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#13 0xb42c2494 in start_thread (arg=0x92c2c090) at pthread_create.c:486
#14 0xb397c578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from
/lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
On Thu, Oct 15, 2020 at 9:36 PM Hy Murveit <murveit at gmail.com> wrote:
> OK, you knew this would happen 10 minutes after I sent that...
>
> log-odds ratio 0.69992 (2.01359), 0 match, 0 conflict, 0 distractors, 17
> index.
> RA,Dec = (309.748,70.6162), pixel scale 4.38547 arcsec/pix.
> log-odds ratio 0.69992 (2.01359), 0 match, 0 conflict, 0 distractors, 17
> index.
> RA,Dec = (309.748,70.6162), pixel scale 4.38547 arcsec/pix.
> log-odds ratio 6.76328 (865.472), 0 match, 0 conflict, 0 distractors, 14
> index.
> RA,Dec = (327.788,50.727), pixel scale 4.50653 arcsec/pix.
> log-odds ratio 6.76328 (865.472), 0 match, 0 conflict, 0 distractors, 14
> index.
> RA,Dec = (327.788,50.727), pixel scale 4.50653 arcsec/pix.
> log-odds ratio 53.7431 (2.18938e+23), 18 match, 0 conflict, 100
> distractors, 37 index.
> RA,Dec = (325.28,58.0466), pixel scale 3.97665 arcsec/pix.
> Hit/miss: Hit/miss:
> +------+----+--------++------------+-+---+-----+--------++--+-----------------++--------------+-----
> Segmentation fault
>
>
> It's hard to say what caused it, but if I had to guess, I'd say it was run
> out of memory.
> It happened during a meridian flip, and perhaps StellarSolver is too
> greedy with memory.
> I'll uncheck that load all indexes flag and continue.
>
> Hy
>
>
>
>
> On Thu, Oct 15, 2020 at 9:23 PM Hy Murveit <murveit at gmail.com> wrote:
>
>> Some good news.
>>
>> Tonight, for the first time, I was able to start up the latest (built
>> from latest source as of an hour before I wrote this) KStars and
>> StellarSolver on my RPi4, without issues (so far).
>> I've polar aligned, plate solved, focused, guiding, ... and so far all
>> good. I have never been able to get to this point with this new software,
>> so there's definitely been progress.
>>
>> Still need to bang on it for several nights, I'm sure, but thanks for the
>> hard work!
>>
>> FWIW, I am not using any of the safeguards I was asked to put in (e.g. I
>> have "Use Scale" and "Load All Indexes In Memory" both checked).
>>
>> Hy
>>
>> On Wed, Oct 14, 2020 at 12:35 PM Hy Murveit <murveit at gmail.com> wrote:
>>
>>> Rob,
>>>
>>> Thanks for your hard work on this!
>>>
>>> As we discussed privately, I have been unable to get plate-solving to
>>> work with the internal StellarSolver on my RPi4.
>>> Do you think this is unique to me--that is, have others been able to do
>>> so? If this a general problem, then I think Oct 22 is too aggressive a
>>> release target, as we should give our advanced users at least a few weeks
>>> of using the software more-or-less successfully on their target
>>> environments. If this is something specific to me, but others are
>>> successfully plate-solving on RPi's, then perhaps I'm over-reacting.
>>>
>>> FWIW, I just tried to send the full bug report I sent you out to this
>>> devel list, but it got blocked (I guess one of my screenshots was too
>>> large).
>>> Hopefully the moderator will accept my thread soon, and it will be
>>> available to all.
>>>
>>> Until that happens, where should we post bugs related to 3.5.0? This
>>> thread? New threads on kstars-devel?
>>>
>>> Again, I want to emphasize that this is a huge undertaking and I
>>> really appreciate the effort,
>>> Hy
>>>
>>>
>>> On Wed, Oct 14, 2020 at 5:47 AM Robert Lancaster <rlancaste at gmail.com>
>>> wrote:
>>>
>>>> Hey guys,
>>>>
>>>> I also agree 100%, we are not ready by Oct. 15th. There are still
>>>> several loose ends that need to be tied up on my end, as well as writing up
>>>> documentation for how to use StellarSolver. Since it is a major release of
>>>> KStars (3.5.0 vs 4.4.4), I think major changes in the UI and the functions
>>>> are perfectly fine, but I agree we don’t want to change everything on the
>>>> user without warning, so we need time to write up documentation and make
>>>> sure everything is clear and simple for the user to use. So please let me
>>>> know what is confusing so that we can try to improve that. As for your
>>>> suggestion that we allow the old code to work during a transition period,
>>>> the issue with that is that the old code is not compatible really. But
>>>> that doesn’t mean that we couldn’t make the UI in the Align module *LOOK*
>>>> like it used to with the combo boxes in align. I put the options for which
>>>> source extraction method, which solving method, and which profile to use
>>>> inside the Options dialog because I thought people would access them less
>>>> often than the other settings in the align module and I also want those to
>>>> be available if we plate solve in other places in KStars. But we could
>>>> also put those same options at the bottom in the align module as well,
>>>> which would make it look close to what it used to look like. There is no
>>>> reason they couldn’t be in both places. It might lead to a better
>>>> transition.
>>>>
>>>> On that note I also agree that we weren’t really ready to put all this
>>>> in KStars master right away, especially because people rely on the master
>>>> branch of the repo for nightly builds, and we needed to test it thoroughly
>>>> before integrating it. I was hoping for more of a testing time period
>>>> where people could test this on my fork or maybe in a different branch in
>>>> the main repo and we could have a nice discussion about how to improve it
>>>> before putting it in the official KStars Master repo. But, let's not be
>>>> too hard on Jasem for that, he is a great guy and works incredibly hard to
>>>> support KStars and INDI and us. It has caused a little more pressure on
>>>> me to fix all these problems and get it all integrated, and maybe that was
>>>> a good thing, because I had mostly finished StellarSolver back in June, and
>>>> I was not integrating it into KStars very fast at all. This has pretty
>>>> much lit a fire under me to get it done. We already did complain to him
>>>> about putting it in the main repo so quickly, but it really has worked to
>>>> get things up and running. So instead of focusing on that, now that its
>>>> done, let's work really hard to polish everything up and get it ready for
>>>> release. I think we could be on track for a Oct 22nd release. Please keep
>>>> testing and I will keep trying to perfect things with StellarSolver and its
>>>> integration with KStars for the release. And I am sorry if the integration
>>>> has caused anybody any issues because it wasn’t ready yet.
>>>>
>>>> Thank you very much,
>>>>
>>>> Rob
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201015/dded7fd3/attachment-0001.htm>
More information about the Kstars-devel
mailing list