| Summary: | KRename process not terminating | ||
|---|---|---|---|
| Product: | [Applications] krename | Reporter: | daniel roi <saarthal> |
| Component: | general | Assignee: | Heiko Becker <heiko.becker> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | greg, gsibk, mafriki, msdobrescu, mvggg, s_chriscollins, t.piekarski |
| Priority: | NOR | Keywords: | investigated, triaged |
| Version: | 5.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=395084 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
daniel roi
2018-09-09 15:14:27 UTC
Hello, I tried to reproduce the bug you reported, but I can not close the window of KRename by pressing Esc when in front the "Find and Replace" window is open. The only window I am able to close is Dolphin itself, you didn't mean that window, did you? :) Can you provide any other information which could help us to reproduce this bug? Tested Versions: krename 5.0.60 (built from most recent commit #9a24890 like you did) dolphin 18.08.1 I've tried again right now. This is what I do: 1. select some files in Dolphin and go to Actions > Rename with Krename 2. click the Find and Replace button 3. click Add, enter something, click Ok, and Ok again 4. click Finish: the "Progress" window appears 5. press Esc: the window closes 6. ps -aux returns this: user 6212 4.1 0.4 512288 72728 ? Sl 14:28 0:00 /usr/bin/krename /data/test1 /data/test2 user 6217 0.0 0.1 148388 17428 ? S 14:28 0:00 file.so [kdeinit5] file local:/run/user/1000/klauncherxFtyvb.1.slave-socket local:/run/user/1000/krenameFEAZUH.1.slave-socket user 6218 0.0 0.1 148388 17428 ? S 14:28 0:00 file.so [kdeinit5] file local:/run/user/1000/klauncherxFtyvb.1.slave-socket local:/run/user/1000/krenamexzcmha.2.slave-socket (In reply to daniel roi from comment #2) > I've tried again right now. This is what I do: Thanks for the steps you described, I can confirm and reproduce this bug. Any news about this bug? According to bug 395084 this should be fixed in master. If you distribution does not offer test builds of unreleased versions, you would need to compile yourself to confirm the fix. Hi, My system is: Operating System: Gentoo Linux KDE Plasma Version: 5.19.2 KDE Frameworks Version: 5.71.0 Qt Version: 5.15.0 Kernel Version: 5.6.0-sabayon OS Type: 64-bit Processors: 8 × Intel® Core™ i7 CPU 920 @ 2.67GHz Memory: 23,5 GiB of RAM Graphics Processor: GeForce GTX 1060 6GB/PCIe/SSE2 The bug is still present. As effect, KRename is restored at login in many instances, when the session restore is set. I too experience an issue with krename not terminating correctly when it is closed. krename output when ran via Konsole (I slightly tided up the output for readability): kf5.kio.core: "Could not enter folder tags:/." kf5.kio.core: We got some errors while running testparm "Unknown parameter encountered: "write cache size" Ignoring unknown parameter "write cache size" Loaded services file OK." kf5.kio.core: We got some errors while running 'net usershare info' kf5.kio.core: "Unknown parameter encountered: "write cache size" Ignoring unknown parameter "write cache size" Unknown parameter encountered: "write cache size" Ignoring unknown parameter "write cache size" info_fn: file /var/lib/samba/usershares/esoaddons is not a well formed usershare file. info_fn: Error was Path is not a directory. " QObject::connect(KRenameModel, KRenameWindow): invalid nullptr parameter And then the process remains. On additional runs krename will hang the plasmashell until it finally struggles through its process. It can take 30 - 300 seconds to do so. I just compiled the latest master from git (version 5.0.60), and this problem appears to be fixed. Can you please try again with 5.0.1? I suspect it's a duplicated of bug 395084 which was confirmed fixed. settings to NEEDSINFO until then I will when my distro will provide it. So far is still 5.0.0. I can confirm processes seem to terminate correctly on 5.0.1. Thanks for the feedback! *** Bug 438034 has been marked as a duplicate of this bug. *** |