Brainstorming on WCS issues

[Hy Murveit]

Based on what I saw from Mohamed's log, I don't think this is the issue.
Still working on it.

On Wed, Sep 29, 2021 at 1:45 PM Hy Murveit <murveit at gmail.com> wrote:

> I'm trying to brainstorm the issue with WCS--from recent crash reports it
> seems likely that there's an issue there.
>
> Here's a not-fully-baked thought:
>
> The issues seem to be related to the multi-threading going on (we add WCS
> data, process it--it has a lot of computation, and then eventually display
> it on the alignview, and do much of this on a separate "Future" thread). We
> fire off the thread, and then do check if it's done before changing images,
> however, I think I found a loophole that may allows old processing to
> continue while the new image is being set up.
>
> Details:
>
> We create a new thread to load WCS, and do significant computation in
> alignview.cpp
>
> https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/alignview.cpp#L54
>
> Then, especially if it's a slower machine, it's possible for a new image
> to arrive before all this work is done.
>
> We protect against this new-image-freeing-old image issue in fitsview.cpp,
>
> https://invent.kde.org/education/kstars/-/blob/master/kstars/fitsviewer/fitsview.cpp#L372
> where we run "wcsWatcher.waitForFinished();" which actually is replicated
> many places in fitsview.cpp.
>
> However, here's my worry: wcswatcher also has a callback set for when it's
> finished, set here
>
> https://invent.kde.org/education/kstars/-/blob/master/kstars/fitsviewer/fitsview.cpp#L203
> so after it's done, it calls syncWCSState(). Which thread does this happen
> on?
>
> So, this syncWCSState() followup might happen before or after the code
> that's waiting for wcsWatcher to be finished. For instance,
> fitsView()::loadData() calls processData() which sets up the new image, but
> at some point, the old syncWCSState() can get called, which calls
> updateFrame() which calls drawOverlay() which calls drawEQGrid().  If there
> was something in the processData() execution flow that would pause and
> allow syncWCSState to run before the imagedata was fully setup,
> drawEQGrid could crash. Nothing is checking to see if syncWCSState() has
> run yet. In fact,
> https://invent.kde.org/education/kstars/-/blob/master/kstars/fitsviewer/fitsview.cpp#L468
> in processData() starts up another loadWCS/wcsWatcher, and the first
> syncWCSState may not yet be done!
>
> Do you think this is a flaw in the current design?
> Hy
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20210929/31fcc480/attachment.htm>