Hi,
First off: I'm sorry if I post this in the wrong way.
I've found a potential issue in the function "find_identical_prefix"
in libsvn_diff/diff_file.c
The faulty code looks like this:
diff_file.c:432 (as per 1.7.1, code identical to 1.7.5)
-------------------------------
is_match = TRUE;
for (delta = 0; delta < max_delta && is_match; delta +=
sizeof(apr_uintptr_t))
{
apr_uintptr_t chunk = *(const apr_size_t *)(file[0].curp + delta);
if (contains_eol(chunk))
break;
for (i = 1; i < file_len; i++)
if (chunk != *(const apr_size_t *)(file[i].curp + delta))
{
is_match = FALSE;
delta -= sizeof(apr_size_t);
break;
}
}
-------------------------------
The problem is that the 64-bit build I'm using (ColabNet) have
different sizes for apr_uintptr_t and apr_size_t.
>From looking at the disassembly I can deduce that
sizeof(apr_uintptr_t) = 4 and sizeof(apr_size_t) = 8. This leads
to these two issues:
1) Data is truncated in the initial read-up to "chunk" and the compare
in the inner loop will fail because the second read-up will compare
a 64-bit value against a 32-bit value.
2) When the test fails it will back up delta by 8, not 4, resulting in
a buffer advance of -4 later in the code. Once the search code has
advanced another 4 character if will be back at the same spot.
Rinse and repeat.
Are these a known issues?
In my case this results in an infinite loop on the following input
string:
23 0a 23 20 54 68 69 73 20 70 72 6f 6a 65 63
I found this out when my svn-client spiraled into an infinite loop
and would not respond to ctrl-c during a "svn up" command.
Regards
/Daniel Widenfalk
