You have been extremely helpful. I appreciate your persistence with this, and your willingness to test and reproduce the issue.
Berthold and I are still struggling to understand how it is possible that this crashed in the first place, and what the fact that my fix appears to work says about the inner workings of the QML threading model. Because, really, really, really - this should never have crashed. And if the UI thread is implemented correctly, my fix shouldn't have fixed it. On the one hand I simply want to merge my fix - on the other hand it always makes me super nervous when it seems we just found a way to hide the symptom of something bigger that might come back to bite us. But again, thank you for your help - much appreciated /D > On Jan 20, 2021, at 11:39 AM, Chirana Gheorghita Eugeniu Theodor > <[email protected]> wrote: > > It is solved. tested and app does not crash anymore. > Hope I've been helpful. > > Thx, > Theodor > > On Wed, Jan 20, 2021, 18:56 Dirk Hohndel <[email protected] > <mailto:[email protected]>> wrote: > And another response to my own post > >> On Jan 19, 2021, at 2:27 PM, Dirk Hohndel via subsurface >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> While cursing into my beard about a completely unrelated issue it suddenly >> occurred to me that I was almost certainly trying to solve the wrong problem. >> It's not the deleteAction that has the signal handler that's still running. >> Because that action isn't deleted. >> What I am now speculating that is happening is slightly more convoluted (I >> absolutely shudder trying to make sense of all this... what a mess). >> So we add this action to the context menu. We do this by adding it to an >> array of actions that is part of the contextDrawer structure. >> From this array of actions the code now builds a repeater that has delegates >> that implement the different entries in the contextDrawer. >> My theory now is that while the manager.deleteDive() is running the dive is >> deleted, the dive list model gets updated, the action becomes invisible, and >> then the delegate gets deleted as it is no longer needed (nothing to show, >> right?). >> But the tap on the menu entry in the context menu caused a signal handler to >> execute (...onClicked()) that was running the onTriggered() signal for the >> deleteAction. So that signal handler isn't finished, because the >> onTriggered() function hasn't completed. >> BOOM >> >> This is rather convoluted and crazy, but I can convince myself that this >> makes sense. Of course, since I can reproduce the issue, I can't test my >> theory. So instead I created this rather interesting patch: > > That line should have read "... Of course, since I CANNOT reproduce the > issue..." > Because I still cannot reproduce it. > But I now have a better implementation of this weird timer based delete > thingy here: https://github.com/subsurface/subsurface/pull/3176 > <https://github.com/subsurface/subsurface/pull/3176> > > This tries to streamline the code, shorten the time window for a race > condition and tries to detect if the user somehow manages to start two > deletes within a hundred ms (wow those are some fast fingers...) > > A new Android build based on the pull request above is on its way through > Google's machine, look for version 3.1.3(4.9.10.402) -- which coincidentally > also includes the new statistics rendering from Berthold that was merged > earlier today... that's why the version number jumped so much. > > /D
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
