https://bugs.kde.org/show_bug.cgi?id=528090
--- Comment #1 from Jason Ross <[email protected]> --- I went through this code on current master (26.11.70) and found a few things that aren't in my report. The crash is still there on master. A small test that destroys the dialog during a hash check and then overwrites its memory, like the stack reuse in the backtrace, segfaults. I made the Close button sound safer than it is. The worker only takes m_closeMutex once it starts running, so if it's still queued in the thread pool, or a second check is waiting (checkHashes() runs again after a download finishes), queryClose() gets the lock straight away and the dialog can still be destroyed under it. Also, queryClose() ends with close(), not accept() as I wrote. There's a separate threading bug too. The itemMatch connect() in the constructor has no context object, so the lambda runs on the worker thread. That means setData(), setIcon(), deleteModel() and accept() are all called off the GUI thread. m_requestClose is also a plain bool, written on the GUI thread and read on the worker. One trap for the fix: if the hash loop is made cancellable, an interrupted check must not emit itemMatch with match=false. The handler treats that as a corrupt file and deletes the model. I have a fix with a regression test working locally and plan to open a merge request. -- You are receiving this mail because: You are watching all bug changes.
