Brainstorming on WCS issues

[Hy Murveit]

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/e1b91447/attachment.htm>