| Summary: | When pasting file using Projects tool view, "File Already Exists" window cannot be interacted with | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Brendon Higgins <brendon> |
| Component: | UI: general | Assignee: | kdevelop-bugs-null |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | aaronw, anarky, b.buschinski, dave, ekigwana, erik.vandevelde, grkavac.igor, igorkuo, master.haber, oss |
| Priority: | HI | ||
| Version: | 5.6.2 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Version of some packages on my system where the bug appears
Reduced KDevelop code that triggers the bug |
||
|
Description
Brendon Higgins
2021-04-01 20:29:00 UTC
Created attachment 137468 [details]
Version of some packages on my system where the bug appears
I can confirm the bug here on a debian/sid (see list of packages version in the file above). Please let me know any additional info I could provide to help you pinpoint the issue. Best, Julien The same bug is present in recent KDevelop master built from sources on Manjaro stable, Xfce. Qt Version: 5.15.2 Frameworks Version: 5.80.0 Windowing System: X11 *** Bug 450316 has been marked as a duplicate of this bug. *** Hi all, The issue is happening due to the blocking calls of KJobs exec() functions that are called every time a Cut/Copy/Paste function is called. The explanation for this behavior can be seen here: https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/jobs/kjob.h#L268 The complete solution would be to abandon synchronous calls and connect signals and slots that wait for the Paste process to finish. I managed to create a working solution for Cut action just to confirm it is doable, however, there is still a lot of refactoring left as a lot of different parts must be changed (ProjectManagerViewPlugin, CutCopyPasteHelper, AbstractFileManagerPlugin, ...) so, if anyone starts working on this, they will probably have a lot of code to write/change. I will continue on this work and if any maintainer confirms this is a good strategy I will create a PR when I'm done. Kind regards, Igor Grkavac > I will continue on this work and if any maintainer confirms this is a good strategy I will create a PR when I'm done.
I don't know if this is a good idea. Other maintainers may not reply here for a very long time. Just go ahead and create a merge request. Eventually it will be reviewed and likely merged. Note that you can create a draft MR - this way your chances of getting early feedback would be somewhat higher than here.
*** Bug 454430 has been marked as a duplicate of this bug. *** *** Bug 457968 has been marked as a duplicate of this bug. *** Created attachment 155130 [details]
Reduced KDevelop code that triggers the bug
(In reply to Igor Grkavac from comment #5) > The issue is happening due to the blocking calls of KJobs exec() functions > that are called every time a Cut/Copy/Paste function is called. > The explanation for this behavior can be seen here: > https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/jobs/ > kjob.h#L268 > > The complete solution would be to abandon synchronous calls and connect > signals and slots that wait for the Paste process to finish. After triggering this bug and being forced to restart KDevelop again, I managed to reduce the code, which causes the bug, to a bare minimum. Attached the patch. "DONE:" is never printed as the bug is triggered; when I send SIGTERM to the kdevelop process, it eventually crashes, but still does not print "DONE:". I think this bug is in KIO, because the KIO::copy() documentation - https://api.kde.org/frameworks/kio/html/classKIO_1_1CopyJob.html, https://api.kde.org/frameworks/kio/html/namespaceKIO.html#a8e3118adc0bb43d03ad15d67bc3d335c - doesn't forbid calling KIO::CopyJob::exec(). Have you considered reporting the KIO bug upstream? *** Bug 468455 has been marked as a duplicate of this bug. *** (In reply to Igor Kushnir from comment #10) > I think this bug is in KIO, because the KIO::copy() documentation - > https://api.kde.org/frameworks/kio/html/classKIO_1_1CopyJob.html, > https://api.kde.org/frameworks/kio/html/namespaceKIO.html#a8e3118adc0bb43d03ad15d67bc3d335c - doesn't forbid calling > KIO::CopyJob::exec(). Have you considered reporting the KIO bug upstream? KJob::isStartedWithExec() was introduced in https://commits.kde.org/kcoreaddons/afe26afee3dfaebdaedeebadb2e0c860c1893093 to warn about calling exec() on a KIO job. But the warning itself hasn't been implemented in KIO. In any case, the best possible likely outcome is that the job would fail semi-silently (with a qWarning) instead of freezing KDevelop. A similar bug in Kate that inspired KJob::isStartedWithExec() was fixed by not calling exec() in https://commits.kde.org/kate/ded94b65ff4fbba38f123a19bcd650e67de711ff. So I believe doing the same, i.e. abandoning synchronous calls, in KDevelop is the right solution. Unfortunately, this correct solution appears to be much harder to implement in KDevelop than in Kate, because the offending exec() calls are located inside deeply nested helper functions, such as KDevelop::copyUrl(). (In reply to Igor Grkavac from comment #5) > The complete solution would be to abandon synchronous calls and connect > signals and slots that wait for the Paste process to finish. > > I managed to create a working solution for Cut action just to confirm it is > doable, however, there is still a lot of refactoring left as a lot of > different parts must be changed (ProjectManagerViewPlugin, > CutCopyPasteHelper, AbstractFileManagerPlugin, ...) so, if anyone starts > working on this, they will probably have a lot of code to write/change. > > I will continue on this work and if any maintainer confirms this is a good > strategy I will create a PR when I'm done. I am prepared to review such a merge request. *** Bug 473894 has been marked as a duplicate of this bug. *** *** Bug 492628 has been marked as a duplicate of this bug. *** fyi still an issue on the latest 6.2.250370 |