KStars 3.6.0 crash

Sat Sep 3 17:33:16 BST 2022

Hi Radek, 

In the cmakelists.txt for stellarsolver, from lines 48-90, there are a couple of tests that get run to set those variables so that we know if a system needs to define qsort related items.  These tests are necessary because different linux and unix systems have or don’t have these features and we need to set or not set them to address those differences for astrometry.net.  I based this code upon what astrometry.net <http://astrometry.net/> does with its os-features-config.h file.  Are you saying that on one or more systems this variable is not getting set correctly?  In all the tests that I did on various systems, the code worked properly.  We should not be setting the RUN_RESULT_2 variable without running the tests because some systems do and others do not have the functions defined the way astrometry wants them.

If there is another way to determine whether these functions need to be defined or variables need to be set that doesn’t require running astrometry.net’s tests, I’m open to that as well, but my understanding is that it is hard to predict without testing them directly.

Thanks,

Rob

> On Aug 18, 2022, at 3:39 PM, Radek Kaczorek <rkaczorek at gmail.com> wrote:
> 
> Final update - issue sorted. Purely related to StellarSolver and not KStars whatsoever.
> 
> While cross-compiling for armhf target on x86_64 host, a user needs to set RUN_RESULT_2 and RUN_RESULT_2 variables appropriately. Otherwise a user can end up with conflicting declaration of C function qsort_r, which is visible only if BUILD_TESTER=ON. Otherwise (stellarmate lib only) compilation completes silently.
> In summary the solution is:
> 1. debian/rules must contain DEB_CMAKE_EXTRA_FLAGS += -C/tmp/TryRunResults.cmake
> 2. /tmp/TryRunResults.cmake must contain:
> set (RUN_RESULT_2 "0" CACHE STRING "Result from TRY_RUN" FORCE)
> set (RUN_RESULT_3 "0" CACHE STRING "Result from TRY_RUN" FORCE)
> 
> Best regards
> 
> Radek Kaczorek
> 
> On Wed, 17 Aug 2022 at 18:38, Radek Kaczorek <rkaczorek at gmail.com <mailto:rkaczorek at gmail.com>> wrote:
> Just to add the full stack trace with libstellarsolver-dbg:
> 
> Thread 27 "ExtractorSolver" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x9476c040 (LWP 3110)]
> 0x9476b6a8 in ?? ()
> (gdb) bt
> #0  0x9476b6a8 in ?? ()
> #1  0xb39177ac in msort_with_tmp (p=0x9476b658, b=0x9476b6f0, n=2490808048) at msort.c:65
> #2  0xb391760c in msort_with_tmp (n=2, b=0x9476b6f0, p=0x9476b658) at msort.c:53
> #3  msort_with_tmp (p=0x9476b658, b=0x9476b6f0, n=2490808048) at msort.c:53
> #4  0xb3917a30 in msort_with_tmp (n=4, b=0x9476b6f0, p=0x9476b658) at msort.c:297
> #5  __GI___qsort_r (b=b at entry=0x9476b6f0, n=n at entry=4, s=s at entry=4, cmp=cmp at entry=0x9476b6a8, arg=0xb5738ba9 <compare_permuted>) at msort.c:297
> #6  0xb5738ca6 in permuted_sort (realarray=realarray at entry=0x9476b758, array_stride=array_stride at entry=8, compare=<optimized out>, perm=perm at entry=0x9476b6f0, N=N at entry=4) at ./stellarsolver/astrometry/util/permutedsort.c:86
> #7  0xb5738752 in healpix_distance_to_xyz (closestxyz=<optimized out>, xyz=<optimized out>, Nside=<optimized out>, hp=<optimized out>) at ./stellarsolver/astrometry/util/healpix.c:1347
> #8  healpix_distance_to_xyz (hp=11, Nside=1, xyz=0x9476b7e8, closestxyz=0x9476b800) at ./stellarsolver/astrometry/util/healpix.c:1314
> #9  0xb57389fe in healpix_distance_to_radec (hp=11, Nside=1, ra=<optimized out>, dec=<optimized out>, closestradec=closestradec at entry=0x0) at ./stellarsolver/astrometry/util/healpix.c:1411
> #10 0xb57249ee in index_is_within_range (meta=meta at entry=0xa77ca2c8, ra=<optimized out>, dec=<optimized out>, radius_deg=15) at ./stellarsolver/astrometry/util/index.c:32
> #11 0xb571d88a in engine_run_job (engine=engine at entry=0xa771fd48, job=0x5f72728) at ./stellarsolver/astrometry/blind/engine.c:520
> #12 0xb56f5d10 in InternalExtractorSolver::runInternalSolver (this=this at entry=0x5f72458) at ./stellarsolver/internalextractorsolver.cpp:1238
> #13 0xb56f8852 in InternalExtractorSolver::run (this=0x5f72458) at ./stellarsolver/internalextractorsolver.cpp:169
> #14 0xb429cb58 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
> #15 0xb5798494 in start_thread (arg=0x9476c040) at pthread_create.c:486
> Backtrace stopped: Cannot access memory at address 0x174
> 
> On Wed, 17 Aug 2022 at 17:46, Radek Kaczorek <rkaczorek at gmail.com <mailto:rkaczorek at gmail.com>> wrote:
> Hi there
> Could you please take a look at this?
> Just to add some details to the message below. I cross-compile to armhf on x86_64 using Debian Buster as a base OS.
> Kind regards
> Radek
> 
> ---------- Forwarded message ---------
> From: Jasem Mutlaq <mutlaqja at ikarustech.com <mailto:mutlaqja at ikarustech.com>>
> Date: Wed, 17 Aug 2022 at 17:39
> Subject: Re: KStars 3.6.0 crash
> To: Radek Kaczorek <rkaczorek at gmail.com <mailto:rkaczorek at gmail.com>>
> 
> 
> Hello Radek,
> 
> We also use the latest (2.4) without issues. Can you please send this to kstars-devel at kde.org <mailto:kstars-devel at kde.org> so that other developer take a look at it and might have some ideas?
> 
> --
> Best Regards,
> Jasem Mutlaq
> 
> 
> 
> On Wed, Aug 17, 2022 at 6:37 PM Radek Kaczorek <rkaczorek at gmail.com <mailto:rkaczorek at gmail.com>> wrote:
> Hi Jasem
> 
> I have recently repackaged KStars 3.6.0 for astroberry and apparently it crashes at plate-solving with stellarsolver. I have used stable-3.6.0 branch of KStars as a source and the latest Stellarsolver, which probably introduces a bug.Which stellarsolver version/commit do you use for  compilation?
> 
> So far I get:
> Thread 37 "ExtractorSolver" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x70498040 (LWP 1965)]
> 0x704976a8 in ?? ()
> (gdb) bt
> #0  0x704976a8 in ?? ()
> #1  0xb39177ac in msort_with_tmp (p=0x70497658, b=0x704976f0, n=1883862768) at msort.c:65
> #2  0xb391760c in msort_with_tmp (n=2, b=0x704976f0, p=0x70497658) at msort.c:53
> #3  msort_with_tmp (p=0x70497658, b=0x704976f0, n=1883862768) at msort.c:53
> #4  0xb3917a30 in msort_with_tmp (n=4, b=0x704976f0, p=0x70497658) at msort.c:297
> #5  __GI___qsort_r (b=0x704976f0, n=4, s=4, cmp=0x704976a8, arg=0xb5738ba9) at msort.c:297
> #6  0xb5738ca6 in permuted_sort () from /usr/lib/arm-linux-gnueabihf/libstellarsolver.so.2
> #7  0xb5738752 in healpix_distance_to_xyz () from /usr/lib/arm-linux-gnueabihf/libstellarsolver.so.2
> #8  0x44aec64c in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Best regards
> 
> Radek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20220903/39752bad/attachment.htm>