STEPS TO REPRODUCE 1. Download https://mesa.freedesktop.org/archive/mesa-19.0.3.tar.gz 2. Download https://mesa.freedesktop.org/archive/mesa-19.0.4.tar.gz 3. tar xf both of them 4. Try to compare them with kdiff3 (git revision: f406df52a4eb2b0004ee040eb9c01e9d8123004f) OBSERVED RESULT Current kdiff3 (git revision: f406df52a4eb2b0004ee040eb9c01e9d8123004f) shows errors and doesn't compare directories successful EXPECTED RESULT kdiff3 working great as before SOFTWARE/OS VERSIONS KDE Frameworks 5.57.0 Qt 5.12.3 (compiled against 5.12.3) Additional Info: I tried git bisect and it tells me c607f4352fadd2bf2480920144b867b9b7922604 is the first bad commit, ec5f96362f2f6eaea8f78fb73da617079723f5b9 still works fine for me.
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.