SUMMARY STEPS TO REPRODUCE 1. Install kdiff3 1.11.1 on MacOS using brew 2. Launch kdiff3 using git mergetool (it launches with --auto --L1 --L2 --L3 -o and redirects stderr to stdout and stdout to /dev/null Example command line: /Applications/kdiff3.app/Contents/MacOS/kdiff3 --auto --L1 'path/to/MyFile.java (Base)' --L2 'path/to/MyFile.java (Local)' --L3 'path/to/MyFile.java (Remote)' -o path/to/MyFile.java ./path/to/MyFile_BASE_31578.java ./path/to/MyFile_LOCAL_31578.java ./path/to/MyFile_REMOTE_31578.java OBSERVED RESULT Floating point exception: 8 EXPECTED RESULT Diff shown SOFTWARE/OS VERSIONS macOS: 14.4.1 KDE Frameworks Version 6.2.0 Qt Version 6.7.0 (built against 6.7.0) ADDITIONAL INFORMATION
This is not just MacOS. Same issue on Manjaro Linux. Most likely a regression, since I think that kdiff3 was working fine until not long ago. Seen with Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.2-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA402RK_GA402RK System Version: 1.0 Application reports org.kde.kdiff3: Diff: A <-> B org.kde.kdiff3: Linediff: A <-> B org.kde.kdiff3: Enter: calcDiff3LineListUsingAB org.kde.kdiff3: Leave: calcDiff3LineListUsingAB Floating point exception (core dumped)
Same issue on MacOS 14.5 / arm64 / Apple Silicon, installed kdiff3 using homebrew. I'm using a workaround to install 1.10.7 for MacOS x86_64 and using that until this is fixed. I have shared my workaround custom cask in https://github.com/lhotari/pulsar-contributor-toolbox/blob/master/tools/kdiff3-x86.rb .
does the version found here: https://download.kde.org/stable/kdiff3/kdiff3-1.11.1-macos-arm64.dmg.mirrorlist show the same issue? If so can you get a stack trace with lldb.
Frustratingly for me, it now works using the same version as before (1.11.1 - and I haven't re-installed since raising this bug) after a reboot and a few weeks of elapsed time during which I've likely changed other things too.
(In reply to Mat from comment #4) > Frustratingly for me, it now works using the same version as before (1.11.1 > - and I haven't re-installed since raising this bug) after a reboot and a > few weeks of elapsed time during which I've likely changed other things too. For me on MacOS 14.5 / arm64, 1.11.1 works for most cases, but it will crash with only certain type contents in the input files.
Unless sample files and or stack trace can be provided there is little I can do. KDiff3 has been found to have odd corner cases in the past the require specific input and actions to trigger.
Providing a test case might not be easy, since code might not be publishable. In any case, if you use the tool yourself, it might be only a matter of time until you get what you need to reproduce the issue. Here, a stack trace might be easier. Can you pls summarize how to get one in Linux?
For linux you would need to either attach the lldb/gdb debugger to kdiff3 or locate the coredump from a crash. Coredumps are not always generated by default on all setup arch does produce them. https://lldb.llvm.org/use/map.html Provides reference for running programs with the debugger attached from the start. The bt command can be used at the when kdiff3 crash to see where this is happening. lldb is generally the default on MacOS must linux systems will have gdb by default. Its understandable that some code can't be published. I'll keep on eye out on my end case too. KDiff3 itself doesn't directly do much with floating point but some of the frameworks its built on do.