Error executing diff command: buffer.inline.h:72
Brought to you by:
blais
Menu
▾
▴
#172 Error executing diff command: buffer.inline.h:72
When trying to diff certain files, I get an error stating:
-----
Error executing "diff" command, could not build diffs:
xxdiff (./buffer.inline.h:72):
Internal error.
-----
Plus, there's some stuff telling me to report the bug and to try the --text
option. If I use the --text option, the result is the same. Either way, I get
this error, and then an empty window after I dismiss the error.
I am running xxdiff on Mac OS X 10.4 using qt3-mac. I had to modify
the makefile that was generated by tmake to get xxdiff to build, and
once I did that, I had to put it in an application bundle (because
programs using qt3-mac use the native windowing system, which
means that they need to have various information associated with them
from the bundle). This seems to work for most files, but fails for certain
combinations of files.
I have included the files that cause this problem. It happens if you do a
two way diff between file1 and file2 in the attached archive. Both of
these files can be diffed with other files just fine; file3 is an example of a
file that they both work with, and they seems to also work with
completely random other files.
I see that this or a similar bug has been reported here on the bug
tracker; I hope that these files I have provided help in finding the bug.
Example files that break xxdiff
Logged In: YES
user_id=4724
i've seen this bug on various files.
i first noticed it when diffing two php files. i eliminated
lines and retried, trying to find what was "causing" it. i
couldn't find the lines. got it down to one line of text in
each file before it would work.
i use this app all the time, i'm sorry that it doesn't work :)
Logged In: YES
user_id=594544
I'm seeing this problem as well.
I'm running under Fedora Core 4 and I wonder if it has to do
with g++ 4.0?
I get the exact same behavior reported here whenever I
xxdiff two files that are not both VERY short.
I just did a test.
This problem seems to go away if you turn off optimization
(take "-O2" out of CFLAGS and CXXFLAGS in Makefile)!!!
At least it works on all my tests!
Logged In: YES
user_id=15179
I'm also only seeing this bug *after* an upgrade to g++ 4.0. Other
Debian users seem to be having the same or similar problems (see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326553\)
*t
Logged In: YES
user_id=228985
for what it's worth, this bug went for me away after
compiled i compiled without -O2. Even -O fails, you really
have to compile without any optimization.
Logged In: YES
user_id=10996
How strange. I cannot reproduce the problem on Linux, with
the given files. Unfortunately, I don't have one of those
expensive Mac computers (yet :-)).
You should compile in debug mode and run in gdb, and send a
stack trace.
BTW at some point I will change the internal representation
of the buffer to support Unicode, and this problem will go
away (although xxdiff internal buffers might a little less
optimized).
Logged In: YES
user_id=15179
> I cannot reproduce the problem on Linux, with the given files.
> Unfortunately, I don't have one of those expensive Mac
computers
> (yet :-)).
Uhm - the problem *does* occur on Linux boxes. AFAIC see the
problem *only* occurs with g++ = 4.0 compilers. Did you
compile with such a compiler?
Particulary in case you have a Debian box, you should be
able to 100% reliably reproduce the problem with any two
files when you compile inside the *unstable* Debian branch.
*t
Logged In: YES
user_id=8488
I am running into the same error in 3.0.4 and 3.1 (except
line 74 instead of 72) on Fedora Core 4 x86.
Odds are it is probably an incompatability with gcc4. And I
just attempted tom compile with the compat-gcc-32-c++
package (make CXX=g++32). However there are lovely linking
issues in finding the stdc++.. ARGHH!!!
Logged In: YES
user_id=10996
I still have not switched to a gcc-4 system, waiting to
check this for some future version.
If you have this problem, please run "diff" on your files
and let me know what the output is.
Logged In: YES
user_id=8488
It builds fine on GCC 4.1 under FC5.:-D