<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Radek, <div class=""><br class=""><div class="">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 <a href="http://astrometry.net" class="">astrometry.net</a>. I based this code upon what <a href="http://astrometry.net" class="">astrometry.net</a> 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.</div><div class=""><br class=""></div><div class="">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 <a href="http://astrometry.net" class="">astrometry.net</a>’s tests, I’m open to that as well, but my understanding is that it is hard to predict without testing them directly.<br class=""><div><br class=""></div><div>Thanks,</div><div><br class=""></div><div>Rob</div><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 18, 2022, at 3:39 PM, Radek Kaczorek <<a href="mailto:rkaczorek@gmail.com" class="">rkaczorek@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Final update - issue sorted. Purely related to StellarSolver and not KStars whatsoever.</div><div class=""><br class=""></div><div class="">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.</div><div class="">In summary the solution is:</div><div class="">1. debian/rules must contain DEB_CMAKE_EXTRA_FLAGS += -C/tmp/TryRunResults.cmake</div><div class="">2. /tmp/TryRunResults.cmake must contain:</div><div class="">set (RUN_RESULT_2 "0" CACHE STRING "Result from TRY_RUN" FORCE)<br class="">set (RUN_RESULT_3 "0" CACHE STRING "Result from TRY_RUN" FORCE)<br class=""></div><div class=""><br class=""></div><div class="">Best regards</div><div class=""><br class=""></div><div class="">Radek Kaczorek<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 17 Aug 2022 at 18:38, Radek Kaczorek <<a href="mailto:rkaczorek@gmail.com" class="">rkaczorek@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">Just to add the full stack trace with libstellarsolver-dbg:</div><div class=""><br class=""></div><div class="">Thread 27 "ExtractorSolver" received signal SIGSEGV, Segmentation fault.<br class="">[Switching to Thread 0x9476c040 (LWP 3110)]<br class="">0x9476b6a8 in ?? ()<br class="">(gdb) bt<br class="">#0 0x9476b6a8 in ?? ()<br class="">#1 0xb39177ac in msort_with_tmp (p=0x9476b658, b=0x9476b6f0, n=2490808048) at msort.c:65<br class="">#2 0xb391760c in msort_with_tmp (n=2, b=0x9476b6f0, p=0x9476b658) at msort.c:53<br class="">#3 msort_with_tmp (p=0x9476b658, b=0x9476b6f0, n=2490808048) at msort.c:53<br class="">#4 0xb3917a30 in msort_with_tmp (n=4, b=0x9476b6f0, p=0x9476b658) at msort.c:297<br class="">#5 __GI___qsort_r (b=b@entry=0x9476b6f0, n=n@entry=4, s=s@entry=4, cmp=cmp@entry=0x9476b6a8, arg=0xb5738ba9 <compare_permuted>) at msort.c:297<br class="">#6 0xb5738ca6 in permuted_sort (realarray=realarray@entry=0x9476b758, array_stride=array_stride@entry=8, compare=<optimized out>, perm=perm@entry=0x9476b6f0, N=N@entry=4) at ./stellarsolver/astrometry/util/permutedsort.c:86<br class="">#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<br class="">#8 healpix_distance_to_xyz (hp=11, Nside=1, xyz=0x9476b7e8, closestxyz=0x9476b800) at ./stellarsolver/astrometry/util/healpix.c:1314<br class="">#9 0xb57389fe in healpix_distance_to_radec (hp=11, Nside=1, ra=<optimized out>, dec=<optimized out>, closestradec=closestradec@entry=0x0) at ./stellarsolver/astrometry/util/healpix.c:1411<br class="">#10 0xb57249ee in index_is_within_range (meta=meta@entry=0xa77ca2c8, ra=<optimized out>, dec=<optimized out>, radius_deg=15) at ./stellarsolver/astrometry/util/index.c:32<br class="">#11 0xb571d88a in engine_run_job (engine=engine@entry=0xa771fd48, job=0x5f72728) at ./stellarsolver/astrometry/blind/engine.c:520<br class="">#12 0xb56f5d10 in InternalExtractorSolver::runInternalSolver (this=this@entry=0x5f72458) at ./stellarsolver/internalextractorsolver.cpp:1238<br class="">#13 0xb56f8852 in InternalExtractorSolver::run (this=0x5f72458) at ./stellarsolver/internalextractorsolver.cpp:169<br class="">#14 0xb429cb58 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5<br class="">#15 0xb5798494 in start_thread (arg=0x9476c040) at pthread_create.c:486<br class="">Backtrace stopped: Cannot access memory at address 0x174</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 17 Aug 2022 at 17:46, Radek Kaczorek <<a href="mailto:rkaczorek@gmail.com" target="_blank" class="">rkaczorek@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">Hi there</div><div class="">Could you please take a look at this?</div><div class="">Just to add some details to the message below. I cross-compile to armhf on x86_64 using Debian Buster as a base OS.</div><div class="">Kind regards</div><div class="">Radek<br class=""></div><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br class="">From: <b class="gmail_sendername" dir="auto">Jasem Mutlaq</b> <span dir="auto" class=""><<a href="mailto:mutlaqja@ikarustech.com" target="_blank" class="">mutlaqja@ikarustech.com</a>></span><br class="">Date: Wed, 17 Aug 2022 at 17:39<br class="">Subject: Re: KStars 3.6.0 crash<br class="">To: Radek Kaczorek <<a href="mailto:rkaczorek@gmail.com" target="_blank" class="">rkaczorek@gmail.com</a>><br class=""></div><br class=""><br class=""><div dir="ltr" class="">Hello Radek,<div class=""><br class=""></div><div class="">We also use the latest (2.4) without issues. Can you please send this to <a href="mailto:kstars-devel@kde.org" target="_blank" class="">kstars-devel@kde.org</a> so that other developer take a look at it and might have some ideas?</div><div class=""><br clear="all" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">--</div><div class="">Best Regards,<br class="">Jasem Mutlaq<br class=""></div><div class=""><br class=""></div></div></div></div></div></div><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 17, 2022 at 6:37 PM Radek Kaczorek <<a href="mailto:rkaczorek@gmail.com" target="_blank" class="">rkaczorek@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">Hi Jasem</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">So far I get:</div><div class="">Thread 37 "ExtractorSolver" received signal SIGSEGV, Segmentation fault.<br class="">[Switching to Thread 0x70498040 (LWP 1965)]<br class="">0x704976a8 in ?? ()<br class="">(gdb) bt<br class="">#0 0x704976a8 in ?? ()<br class="">#1 0xb39177ac in msort_with_tmp (p=0x70497658, b=0x704976f0, n=1883862768) at msort.c:65<br class="">#2 0xb391760c in msort_with_tmp (n=2, b=0x704976f0, p=0x70497658) at msort.c:53<br class="">#3 msort_with_tmp (p=0x70497658, b=0x704976f0, n=1883862768) at msort.c:53<br class="">#4 0xb3917a30 in msort_with_tmp (n=4, b=0x704976f0, p=0x70497658) at msort.c:297<br class="">#5 __GI___qsort_r (b=0x704976f0, n=4, s=4, cmp=0x704976a8, arg=0xb5738ba9) at msort.c:297<br class="">#6 0xb5738ca6 in permuted_sort () from /usr/lib/arm-linux-gnueabihf/libstellarsolver.so.2<br class="">#7 0xb5738752 in healpix_distance_to_xyz () from /usr/lib/arm-linux-gnueabihf/libstellarsolver.so.2<br class="">#8 0x44aec64c in ?? ()<br class="">Backtrace stopped: previous frame identical to this frame (corrupt stack?)</div><div class=""><br class=""></div><div class="">Best regards</div><div class=""><br class=""></div><div class="">Radek<br class=""></div></div>
</blockquote></div>
</div></div></div>
</blockquote></div>
</blockquote></div>
</div></blockquote></div><br class=""></div></div></body></html>