Accidental file delete on mobile.

Dirk Hohndel dirk at hohndel.org
Wed Jan 20 11:55:03 PST 2021


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 <office at adaptcom.ro> 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 <dirk at hohndel.org <mailto:dirk at hohndel.org>> wrote:
> And another response to my own post
> 
>> On Jan 19, 2021, at 2:27 PM, Dirk Hohndel via subsurface <subsurface at subsurface-divelog.org <mailto:subsurface at 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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20210120/73ca79a3/attachment-0001.htm>


More information about the subsurface mailing list