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 <d...@hohndel.org> wrote: > And another response to my own post > > On Jan 19, 2021, at 2:27 PM, Dirk Hohndel via subsurface < > subsurface@subsurface-divelog.org> 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 > > 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 subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface