| Summary: | kdiff3 fails to compare directories since c607f4352fadd2bf2480920144b867b9b7922604 | ||
|---|---|---|---|
| Product: | [Applications] kdiff3 | Reporter: | Timo Gurr <timo.gurr> |
| Component: | application | Assignee: | michael <reeves.87> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | paolo.greppi, phoenix_firebrd, vkrevs |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
attachment-11541-0.html
attachment-14120-0.html |
||
|
Description
Timo Gurr
2019-05-10 13:16:55 UTC
What is the first error message? I can't reproduce this on my machine. Look for "kdiff3part.so" and see if there are multiple copies. This file sometimes is not install to the correct location with the default cmake configuration. This issue sounds like one I fixed during testing. kdiff3 /usr/include /usr/include is the simplest way to reproduce. kdiff3-1.8.1-lp150.18.1.x86_64 plasma-framework-5.58.0-lp150.249.1.x86_64 plasma5-workspace-5.15.90-lp150.456.1.x86_64 libQt5Core5-5.12.3-lp150.2.1.x86_64 this looks the same as: https://bugs.debian.org/920976 (although I can't be sure since the submitter never described the exact error message) here is how you can easily reproduce: rm -rf /tmp/test1 /tmp/test2 mkdir /tmp/test1 /tmp/test2 touch /tmp/test1/a /tmp/test2/a kdiff3 /tmp/test1 /tmp/test2 before the kdiff3 main window opens, a pop-up opens with title "Error", main message "Some files could ot be processed", detailed message: "Opening /tmp/test1/a failed: no such file or directory" Please check if this issue is due to Dos/Windows-Unix Line ending conflict Created attachment 121603 [details]
attachment-11541-0.html
I don't know what prompted this suggestion but do me a favor. Please read
through kdiff3's file processing code before comment ing further. Kdiff3
converts line endings to unicorn style before even attempting to compare
files. They are covered back on only when saving changes. So this is
unlikely in the extreme to be the answer for this issue.
>
>
Created attachment 121608 [details]
attachment-14120-0.html
That word should be unix not unicorn. Apparently my phone likes unicorns.
@paolog that appears an unrelated and resolved in 1.8.0 issue see the debian bug. I believe this issue is fixed as of https://cgit.kde.org/kdiff3.git/commit/?h=1.8&id=804997e45675e1ea1e86559d11f118d73fca8ce0 Could the Timo Gurr please confirm this. (In reply to michael from comment #7) > @paolog that appears an unrelated and resolved in 1.8.0 issue see the debian > bug. > > I believe this issue is fixed as of > https://cgit.kde.org/kdiff3.git/commit/?h=1. > 8&id=804997e45675e1ea1e86559d11f118d73fca8ce0 > > Could the Timo Gurr please confirm this. Applying the mentioned patch to kdiff3 1.8.1 doesn't fix anything for me. Git master with the current rev a8bcf7a6a45e023844ef057bb568e59b2864431f and trying again the steps in #1 allows kdiff3 to load without any errors however it still doesn't work properly. For example in the diff of the directories between mesa-19.0.3 and mesa-19.0.4 I can succesfully e.g. the files VERSION or meson.build, but it fails hard on configure.ac. There seems to be a memleak or something since as soon as I click on configure.ac kdiff begins filling up system memory until it consumes everything available and renders the system unusable. The leak in master is fixed now. Will have another look at ec5f96362f2f6eaea8f78fb73da617079723f5b9 not sure why that would have broken comparisons. Git master as of ec2862517d9f32e0c2e3ab71f4eb03688a546ade seems to work fine for me, I'm now not able to reproduce any sort of crash anymore with my test case mentioned in #1. Glad to here it. The issue your experiencing does not seem to happen on my system. There is no error or crash on 1.8 or master. The change cited by git bisect creates to simple wrapper functions. Literally just one-liners identical to what was already there. Closing this as it seems to work for you. I cann't do anything more to track it down based on the information you provided. |