From kstars-devel Sat Aug 20 18:14:12 2022 From: Akarsh Simha Date: Sat, 20 Aug 2022 18:14:12 +0000 To: kstars-devel Subject: Re: Kstars 3.6.0 MacOS find Object crash Message-Id: X-MARC-Message: https://marc.info/?l=kstars-devel&m=166101900608935 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--0000000000002faddf05e6b02fe1" --0000000000002faddf05e6b02fe1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bravissimo! This is some very patient analysis on your part Robert. I was very nervous when introducing concurrency in the find dialog because concurrency just makes things so much harder to debug and stuff. I=E2=80=99= m strapped for time for the next few months, so I don=E2=80=99t know when I c= an look at it, but the moment I can I=E2=80=99ll see if I missed something in the Q= Thread API. If anyone knows a lot about Qt=E2=80=99s concurrency framework, I=E2= =80=99d be grateful if they could take a look. On Fri, Aug 19, 2022 at 22:01 Robert Lancaster wrote: > Hey guys, > > > Ok, I dug into this and ran a bunch of tests. I don=E2=80=99t know why t= his crash > only occurs when running by double clicking the app and not by running fr= om > Terminal or QT Creator. It is very inconvenient to have an error that > won=E2=80=99t happen when you run the code in a debugger and then will ha= ppen every > time if you don=E2=80=99t! I had thought that maybe it was something wit= h 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=E2=80=99t fully ruled ou= t > something with MacOS, but I don=E2=80=99t 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=E2=80=99t 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 entire= ly > 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 veri= fy > if the new AsynchDBManger was really the culprit. And yes, it worked fin= e > 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 m= y > test QMessageBox message in just after line 772: > > m_thread->start(); > > > It didn=E2=80=99t crash when it printed my debug QMessagebox but it did c= rash when > I didn=E2=80=99t 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 sle= ep > 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 > > Thanks, > > Rob > > > On Aug 17, 2022, at 2:06 AM, Jasem Mutlaq 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 > wrote: > >> Ok I did some more testing. >> >> This commit is when the Find Dialog broke when running KStars on MacOS b= y >> double clicking the app: >> >> >> https://github.com/KDE/kstars/commit/5a2ba9f8e8b275f44b7593a50ca66f09cb2= f985d#diff-c2a2ab763404c18a2daee3feb8b31f2ec278034e7cc720870c4e5158081e0ee9 >> >> I think that is the one you were hoping was not the one. I still don=E2= =80=99t >> 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 click= ing >> that is the problem. >> >> Note that I did test playing with the environment variables in qt creato= r >> and that seemed to have no effect. And it also didn=E2=80=99t seem to m= atter >> whether kstars was packaged up or not, so it doesn=E2=80=99t seem to be = a packaging >> issue. >> >> On Aug 16, 2022, at 2:11 PM, Akarsh Simha wrote: >> >> If I am to blame for this, the parallelism introduced in the asynchronou= s >> find dialog is my suspect, rather than the comet regex (which was actual= ly >> 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 >> 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 bui= ld >>> DMGs that will work with older Macs and have all the features we want i= n >>> 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 doubl= e >>> clicking it crashes when you first access the find dialog. This seems = to >>> me to indicate an environment issue, like maybe an issue with environme= nt >>> variables or maybe a link to a library that isn=E2=80=99t properly in t= he app. I >>> will check further. >>> >>> Thanks, >>> >>> Rob >>> >>> On Aug 13, 2022, at 6:09 AM, John Evans >>> 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 >>> wrote: >>> >>>> >>>> >>>> On Sat, Aug 13, 2022 at 01:27 Peter Amerl 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 versio= n >>>> / 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 threa= d. 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 >>>>> >>>>> >>>>> >>> >> > --0000000000002faddf05e6b02fe1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bravissimo! This is some very patient analysis on your pa= rt Robert. I was very nervous when introducing concurrency in the find dial= og because concurrency just makes things so much harder to debug and stuff.= I=E2=80=99m strapped for time for the next few months, so I don=E2=80=99t = know when I can look at it, but the moment I can I=E2=80=99ll see if I miss= ed something in the QThread API. If anyone knows a lot about Qt=E2=80=99s c= oncurrency framework, I=E2=80=99d be grateful if they could take a look.


On Fri, Aug 19, 2022 at 22:01 Robert Lancaste= r <rlancaste@gmail.com> wr= ote:
Hey guys,

=C2=A0
Ok= , I dug into this and ran a bunch of tests.=C2=A0 I don=E2=80=99t know why = this crash only occurs when running by double clicking the app and not by r= unning from Terminal or QT Creator.=C2=A0 It is very inconvenient to have a= n error that won=E2=80=99t happen when you run the code in a debugger and t= hen will happen every time if you don=E2=80=99t!=C2=A0 I had thought that m= aybe it was something with MacOS sandboxing or gatekeeper, or maybe it was = something with packaging, or maybe it was something with environment variab= les.=C2=A0 But as far as I could tell through my tests it is none of those.= =C2=A0 I printed the environments in a QMessagebox and they were slightly d= ifferent, but not in any way that mattered I think.=C2=A0 The packaging was= not the culprit because it happened in the app both before and after packa= ging and I was running it on the same machine, so it should not be the issu= e.=C2=A0 I haven=E2=80=99t fully ruled out something with MacOS, but I don= =E2=80=99t currently think that is what it is since there was no error mess= age or warning that pops up about the app being blocked from doing somethin= g it wasn=E2=80=99t supposed to.

So then I proceeded to = experiment with the changes in that one Commit.=C2=A0 I first tried narrowi= ng down where the problem was by copying and pasting code from before or af= ter the commit and testing.=C2=A0 That let me rule out a lot of the commit.= =C2=A0 Then I added some Qmessagebox debug dialogs to see exactly when it w= ould fail.=C2=A0 As of now, it seems that the crash is entirely based on wh= at happens when constructing the Find Dialog in find dialog.cpp.=C2=A0 Spec= ifically, it happens here:

m_asy=
ncDBManager(new Cat=
alogsDB::As=
yncDBManager(CatalogsDB::dso_db_path()))

On line 65 wh= en it constructs the new Asynch DB Manager. I did try changing the couple o= f lines of code in find dialog.cpp and find dialog.h so that it would use t= he old manager code from before this commit to verify if the new AsynchDBMa= nger was really the culprit.=C2=A0 And yes, it worked fine with the old cod= e.=C2=A0 So then I changed it back.=C2=A0 Then I played around with the con= structor for that class. Very strangely, I found that when I put my test QM= essageBox message in just after line 772:

m_thr=
ead->s=
tart();

It didn=E2=80=99t crash when it prin= ted my debug QMessagebox but it did crash when I didn=E2=80=99t have it the= re!=C2=A0 That got me thinking that maybe for some reason, this object need= ed a little more time in its constructor for some reason, even though there= are no more commands after that.=C2=A0 So I just added a sleep command to = see if that would serve the same purpose and it worked!

QThread::msl=
eep(100);=

So I would really like to know why this wor= ks.=C2=A0 Here is a commit with a band aid for you guys to take a look at:<= /div>


Thanks,
<= br>
Rob


On Aug 17, 2022, at 2:06 AM, Jasem Mutlaq <mutlaqja@ikarustech.com> w= rote:

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=C2=A0PI, Wid= ows, or any x86-64 machine.

--
Best Regards,
Jasem Mutlaq

<= /div>


On Wed, Aug 17, 2022 at 8:52 AM Robe= rt Lancaster <r= lancaste@gmail.com> wrote:
Ok I did s= ome more testing.

This commit is when the Find Dialog br= oke when running KStars on MacOS by double clicking the app:

=

I think t= hat is the one you were hoping was not the one.=C2=A0 I still don=E2=80=99t= know why it broke it though.=C2=A0 Every time I run it from terminal or qt= creator there is no problem.=C2=A0 It is just when running it by double cl= icking that is the problem.

Note that I did test p= laying with the environment variables in qt creator and that seemed to have= no effect.=C2=A0 And it also didn=E2=80=99t seem to matter whether kstars = was packaged up or not, so it doesn=E2=80=99t seem to be a packaging issue.=

On Aug 16, 2022, at 2:11 PM, Ak= arsh Simha <a= karshsimha@gmail.com> wrote:

If I am= to blame for this, the parallelism introduced in the asynchronous find dia= log is my suspect, rather than the comet regex (which was actually Hy and n= ot me). The regex seems unlikely to cause the erratic behavior Robert is ob= serving where it runs fine under a debugger.

But if it works fine when running KStars from a comman= d line, that probably exonerates me and Hy, and is likely an environment is= sue like Robert points out!

Regards
Akarsh

=

O= n Tue, Aug 16, 2022 at 07:28 Robert Lancaster <rlancaste@gmail.com> wrote:
Hey guys,

I just got back from my= two week trip to the Southwest.=C2=A0 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. =C2=A0
<= br>
Next we can look into this Find Dialog bug.=C2=A0 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 dou= ble clicking it crashes when you first access the find dialog.=C2=A0 This s= eems to me to indicate an environment issue, like maybe an issue with envir= onment variables or maybe a link to a library that isn=E2=80=99t properly i= n the app.=C2=A0 I will check further.

Thanks,

Rob

On Aug 13, 2022, at 6:09 AM, John Evans <john.e.evans.email@gmail.com= > wrote:

I have the same problem with= 3.6.0. Crashes everytime=C2=A0the find object dialog is invoked (button, k= eyboard, 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=C2=A0scheduler enter some text in the object= field (doesn't matter what) and hit the=C2=A0+ to use sky coordinates = from the map.

On Sat, 13 Aug 2022 at 10:05, Akarsh Simha <akarshsimha@gmail.com> wrote:


On Sat, Aug 13, 2022= at 01:27 Peter Amerl <pvamerl@gmail.com> wrote:
Hi All, Has anyone else experienced an immediate crash when searching for objects o= n 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 p= ast, could you provide the exact version / git commit, and also your curren= t version / git =C2=A0commit that has the bug? I made several changes to th= e Find Dialog in the most recent version, notably performing asynchronous d= atabase 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





--0000000000002faddf05e6b02fe1--