<div dir="ltr">Based on what I saw from Mohamed's log, I don't think this is the issue.<div>Still working on it.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 29, 2021 at 1:45 PM Hy Murveit <<a href="mailto:murveit@gmail.com">murveit@gmail.com</a>> wrote:<br></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">I'm trying to brainstorm the issue with WCS--from recent crash reports it seems likely that there's an issue there.<div><div><br></div><div>Here's a not-fully-baked thought:</div><div><br></div><div>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.<br></div><div><br></div><div>Details:</div><div><br></div><div>We create a new thread to load WCS, and do significant computation in alignview.cpp</div><div><a href="https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/alignview.cpp#L54" target="_blank">https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/alignview.cpp#L54</a><br></div><div><br></div><div>Then, especially if it's a slower machine, it's possible for a new image to arrive before all this work is done.</div><div><br></div><div>We protect against this new-image-freeing-old image issue in fitsview.cpp, </div><div><a href="https://invent.kde.org/education/kstars/-/blob/master/kstars/fitsviewer/fitsview.cpp#L372" target="_blank">https://invent.kde.org/education/kstars/-/blob/master/kstars/fitsviewer/fitsview.cpp#L372</a><br></div><div>where we run "<span>wcsWatcher</span><span>.</span><span>waitForFinished</span><span>();" which actually is replicated many places in fitsview.cpp.</span></div><div><br></div><div>However, here's my worry: wcswatcher also has a callback set for when it's finished, set here</div><div><a href="https://invent.kde.org/education/kstars/-/blob/master/kstars/fitsviewer/fitsview.cpp#L203" target="_blank">https://invent.kde.org/education/kstars/-/blob/master/kstars/fitsviewer/fitsview.cpp#L203</a><br></div><div>so after it's done, it calls syncWCSState(). Which thread does this happen on?</div><div><br></div><div>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, <a href="https://invent.kde.org/education/kstars/-/blob/master/kstars/fitsviewer/fitsview.cpp#L468" target="_blank">https://invent.kde.org/education/kstars/-/blob/master/kstars/fitsviewer/fitsview.cpp#L468</a> in processData() starts up another loadWCS/wcsWatcher, and the first syncWCSState may not yet be done!</div><div><br></div><div>Do you think this is a flaw in the current design?</div><div>Hy</div><div><br></div><div><br></div></div></div>
</blockquote></div>