Re: [BUG+PATCH] Repository "corruption" when committing several versions of a huge file

On Tuesday, November 29, 2011 2:47 PM, "Martin Buck" <mb-tmp-fhoirefvba.ncnpur.bet_at_gromit.dyndns.org> wrote:
> The problem is that subversion/libsvn_fs_fs/fs_fs.c:read_rep_line()
> correctly parses the size of the base revision for r2 as a 64 bit number,
> but then stores it in an apr_off_t which is 32 bits on my machine.
>

Why isn't apr_off_t 64 bits?

> The attached patch fixes the bug for me. Does anybody see a problem with it?
> Could somebody please commit it or should I open an issue in the tracker?
>
> Thanks,
> Martin
>
> Email had 1 attachment:
> + large-file-repo-corruption-fix.diff
> 1k (text/x-diff)

> --- subversion-1.7.1/subversion/libsvn_fs_fs/fs_fs.c.orig 2011-10-19 19:28:55.000000000 +0200
> +++ subversion-1.7.1/subversion/libsvn_fs_fs/fs_fs.c 2011-11-25 16:53:56.000000000 +0100
> @@ -2575,7 +2575,7 @@
>
> svn_revnum_t base_revision;
> apr_off_t base_offset;
> - apr_size_t base_length;
> + svn_filesize_t base_length;

I'd like both BASE_OFFSET and BASE_LENGTH to be 64 bit types. Would it
work to make them both svn_filesize_t?

> };
>
> /* Read the next line from file FILE and parse it as a text
> @@ -2636,7 +2636,7 @@
> if (! str)
> goto error;
> SVN_ERR(svn_cstring_atoi64(&val, str));
> - rep_args->base_length = (apr_size_t)val;
> + rep_args->base_length = (svn_filesize_t)val;
>
> *rep_args_p = rep_args;
> return SVN_NO_ERROR;

Are there other instances of this problem in our code? (I'll look
myself later, but if you know or can easily find such it'll save me time
if you identified them.)

Thanks,

Daniel
Received on 2011-11-29 15:33:14 CET