[prev in list] [next in list] [prev in thread] [next in thread]
List: kstars-devel
Subject: Re: Kstars 3.6.0 MacOS find Object crash
From: Peter Amerl <pvamerl () gmail ! com>
Date: 2022-08-21 2:43:55
Message-ID: C0824747-64AB-4D79-831B-1E5F12B6CD42 () gmail ! com
[Download RAW message or body]
Hi All,
Just in case it is important, last night I tried out starting the executable from the command line, with \
the same Application crash whenever I tried the find operation, either by Apple-f or by selecting it \
through the menu system with the mouse. … sorry if someone already knows this to be the case … just \
trying to avoid a red herring due to lack of information.
Regards,
Peter
> On 20 Aug 2022, at 20:30, kstars-devel-request@kde.org wrote:
>
> Send Kstars-devel mailing list submissions to
> kstars-devel@kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.kde.org/mailman/listinfo/kstars-devel
> or, via email, send a message with subject or body 'help' to
> kstars-devel-request@kde.org
>
> You can reach the person managing the list at
> kstars-devel-owner@kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kstars-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Kstars 3.6.0 MacOS find Object crash (Robert Lancaster)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 20 Aug 2022 01:01:35 -0400
> From: Robert Lancaster <rlancaste@gmail.com>
> To: Jasem Mutlaq <mutlaqja@ikarustech.com>
> Cc: KStars Development Mailing List <kstars-devel@kde.org>
> Subject: Re: Kstars 3.6.0 MacOS find Object crash
> Message-ID: <5B5B9058-0EFD-4F8F-BE25-B329CC3ED597@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hey guys,
>
>
> Ok, I dug into this and ran a bunch of tests. I don't know why this crash only occurs when running by \
> double clicking the app and not by running from Terminal or QT Creator. It is very inconvenient to \
> have an error that won't happen when you run the code in a debugger and then will happen every time if \
> you don't! I had thought that maybe it was something with MacOS sandboxing or gatekeeper, or maybe it \
> was something with packaging, or maybe it was something with environment variables. But as far as I \
> could tell through my tests it is none of those. I printed the environments in a QMessagebox and they \
> were slightly different, but not in any way that mattered I think. The packaging was not the culprit \
> because it happened in the app both before and after packaging and I was running it on the same \
> machine, so it should not be the issue. I haven't fully ruled out something with MacOS, but I don't \
> currently think that is what it is since there was no error message or warning that pops up about the \
> app being blocked from doing something it wasn't supposed to.
> So then I proceeded to experiment with the changes in that one Commit. I first tried narrowing down \
> where the problem was by copying and pasting code from before or after the commit and testing. That \
> let me rule out a lot of the commit. Then I added some Qmessagebox debug dialogs to see exactly when \
> it would fail. As of now, it seems that the crash is entirely based on what happens when constructing \
> the Find Dialog in find dialog.cpp. Specifically, it happens here:
> m_asyncDBManager(new CatalogsDB::AsyncDBManager(CatalogsDB::dso_db_path()))
>
> On line 65 when it constructs the new Asynch DB Manager. I did try changing the couple of lines of code \
> in find dialog.cpp and find dialog.h so that it would use the old manager code from before this commit \
> to verify if the new AsynchDBManger was really the culprit. And yes, it worked fine with the old code. \
> So then I changed it back. Then I played around with the constructor for that class. Very strangely, I \
> found that when I put my test QMessageBox message in just after line 772:
> m_thread->start();
>
> It didn't crash when it printed my debug QMessagebox but it did crash when I didn't have it there! \
> That got me thinking that maybe for some reason, this object needed a little more time in its \
> constructor for some reason, even though there are no more commands after that. So I just added a \
> sleep command to see if that would serve the same purpose and it worked!
> QThread::msleep(100);
>
> So I would really like to know why this works. Here is a commit with a band aid for you guys to take a \
> look at:
> https://invent.kde.org/education/kstars/-/merge_requests/706 \
> <https://invent.kde.org/education/kstars/-/merge_requests/706>
> Thanks,
>
> Rob
>
>
> > On Aug 17, 2022, at 2:06 AM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
> >
> > I received one report for Find Dialog crash as well on Raspberry Pi, so perhaps it's not unique to \
> > MacOS?
> > However, I couldn't reproduce on Raspberry PI, Widows, or any x86-64 machine.
> >
> > --
> > Best Regards,
> > Jasem Mutlaq
> >
> >
> >
> > On Wed, Aug 17, 2022 at 8:52 AM Robert Lancaster <rlancaste@gmail.com <mailto:rlancaste@gmail.com>> \
> > wrote: Ok I did some more testing.
> >
> > This commit is when the Find Dialog broke when running KStars on MacOS by double clicking the app:
> >
> > https://github.com/KDE/kstars/commit/5a2ba9f8e8b275f44b7593a50ca66f09cb2f985d#diff-c2a2ab763404c18a2daee3feb8b31f2ec278034e7cc720870c4e5158081e0ee9 \
> > <https://github.com/KDE/kstars/commit/5a2ba9f8e8b275f44b7593a50ca66f09cb2f985d#diff-c2a2ab763404c18a2daee3feb8b31f2ec278034e7cc720870c4e5158081e0ee9>
> >
> > I think that is the one you were hoping was not the one. I still don't know why it broke it though. \
> > Every time I run it from terminal or qt creator there is no problem. It is just when running it by \
> > double clicking that is the problem.
> > Note that I did test playing with the environment variables in qt creator and that seemed to have no \
> > effect. And it also didn't seem to matter whether kstars was packaged up or not, so it doesn't seem \
> > to be a packaging issue.
> > > > On Aug 16, 2022, at 2:11 PM, Akarsh Simha <akarshsimha@gmail.com <mailto:akarshsimha@gmail.com>> \
> > > > wrote:
> > >
> > > If I am to blame for this, the parallelism introduced in the asynchronous find dialog is my \
> > > suspect, rather than the comet regex (which was actually Hy and not me). The regex seems unlikely \
> > > to cause the erratic behavior Robert is observing where it runs fine under a debugger.
> > > But if it works fine when running KStars from a command line, that probably exonerates me and Hy, \
> > > and is likely an environment issue like Robert points out!
> > > Regards
> > > Akarsh
> > >
> > >
> > > > On Tue, Aug 16, 2022 at 07:28 Robert Lancaster <rlancaste@gmail.com <mailto:rlancaste@gmail.com>> \
> > > > wrote:
> > > Hey guys,
> > >
> > > I just got back from my two week trip to the Southwest. Yesterday I resolved the issue with \
> > > building a dmg with my script, so now I can build DMGs that will work with older Macs and have all \
> > > the features we want in the dmg.
> > > Next we can look into this Find Dialog bug. I did some experiments today and I found that if I run \
> > > kstars from the command line or in a debugger, the find dialog works fine, but when running the app \
> > > by double clicking it crashes when you first access the find dialog. This seems to me to indicate \
> > > an environment issue, like maybe an issue with environment variables or maybe a link to a library \
> > > that isn't properly in the app. I will check further.
> > > Thanks,
> > >
> > > Rob
> > >
> > > > On Aug 13, 2022, at 6:09 AM, John Evans <john.e.evans.email@gmail.com \
> > > > <mailto:john.e.evans.email@gmail.com>> wrote:
> > > > I have the same problem with 3.6.0. Crashes everytime the find object dialog is invoked (button, \
> > > > keyboard, etc.)
> > > > Works great when I run it in debug in Qt though.
> > > >
> > > > Workaround is to use the skymap and click on the object you want. In the scheduler enter some \
> > > > text in the object field (doesn't matter what) and hit the + to use sky coordinates from the map. \
> > > > On Sat, 13 Aug 2022 at 10:05, Akarsh Simha <akarshsimha@gmail.com \
> > > > <mailto:akarshsimha@gmail.com>> wrote:
> > > >
> > > > On Sat, Aug 13, 2022 at 01:27 Peter Amerl <pvamerl@gmail.com <mailto:pvamerl@gmail.com>> wrote:
> > > > Hi All,
> > > > Has anyone else experienced an immediate crash when searching for objects on a Mac using the \
> > > > Apple-f key combination? I can confirm that it has worked in the past without a crash. Neither \
> > > > Ctrl-f, nor selecting it from the menu appears to work for me at this time. The Crash trace is \
> > > > appended in the zip if anyone wants to have a look.
> > > > Hi Peter
> > > >
> > > > When you say it worked in the past, could you provide the exact version / git commit, and also \
> > > > your current version / git commit that has the bug? I made several changes to the Find Dialog in \
> > > > the most recent version, notably performing asynchronous database queries through another thread. \
> > > > It never crashed on my Linux system. Also curious if someone else can reproduce it on MacOS or if \
> > > > it is unique to your system.
> > > > Regards
> > > > Akarsh
> > > >
> > > >
> > > > Cheers,
> > > > Peter
> > > >
> > > >
> > >
> >
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20220820/4f452c3d/attachment-0001.htm>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
>
>
> ------------------------------
>
> End of Kstars-devel Digest, Vol 223, Issue 9
> ********************************************
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic