Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of Daniel.Widenfalk@iar.com
 designates 193.58.238.150 as permitted sender)
Message-ID: <4FD06F11.1010607@iar.se>
Date: Thu, 07 Jun 2012 11:06:25 +0200
From: Daniel Widenfalk <Daniel.Widenfalk@iar.se>
Organization: IAR Systems AB
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: dev@subversion.apache.org, users@subversion.apache.org
Subject: Potential issue in libsvn_diff:diff_file.c:find_identical_prefix
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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