Thx. Attached log to see it working. Maibe it points whybit is working.. On Wed, Jan 20, 2021, 21:55 Dirk Hohndel <[email protected]> wrote:
> 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]> wrote: > >> And another response to my own post >> >> On Jan 19, 2021, at 2:27 PM, Dirk Hohndel via subsurface < >> [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 >> >> 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.log
Description: Binary data
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
