[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Error E140001: Sum of subblock sizes larger than total block content length

From: Julian Foad <julianfoad_at_apache.org>
Date: Thu, 23 Nov 2017 12:17:16 +0100

Ronald Taneza wrote:
> Hi Julian,
> Thank you for your quick response and patch. I hope that this is fixed
> in the next 1.8.x release and that CollabNet will also release an update
> to Subversion Edge.

It should be.

> I'm still not so clear how this is exactly a problem with svnrdump
> 1.8.19 (from Subversion Edge). This is my first time browsing through
> the svn source code, and I hope you'll indulge me with my questions below.
> We are using Subversion Edge 5.2.2 (Windows 64-bit) on a Windows Server
> 2012 (64-bit) OS.

This bug occurred because the "%ld" format and/or the 'long' data type
were 32-bit. This is indeed the case:

On 64-bit Windows, 'long' is a 32-bit type (and 'long long' is 64-bit;
on most other platforms both are 64-bit.)


> I also verified that the httpd.exe, svn.exe, and svnrdump.exe binaries
> are 64-bit. (I ran the "file xxx" command in Cygwin and also checked
> their PE signatures as described here:
> https://superuser.com/questions/358434/how-to-check-if-a-binary-is-32-or-64-bit-on-windows).
> You mentioned:
> > SVN_ERR(svn_stream_printf(eb->stream, pool,
>                                SVN_REPOS_DUMPFILE_CONTENT_LENGTH
>                               ": %ld\n\n",
>                               (unsigned long)info->size +
>                                 propstring->len));
> > info->size is apr_off_t ... probably 64 bits on most systems.
> > propstring->len is apr_size_t ... probably 64 bits on most systems.

I was wrong about that: apr_size_t would be 32-bit on 32-bit
architectures. File sizes (apr_off_t) are more likely to be 64-bit,
although there may be some platforms where they are 32-bit, maybe
depending on compile-time options or something that is configurable.

Therefore my initial patch (changing to use APR_SIZE_T_FMT) was wrong
(would not have worked on 32-bit architectures). I have now corrected
that to use APR_OFF_T_FMT.

> > It uses "%lu" for the text content, which thus work OK up to 4 GB,
> and "%ld" for the overall content length which thus only works up to 2 GB.

When I wrote that, I was assuming a 32-bit architecture.

> On a 64-bit system where unsigned long is uint64:

On a standard Windows-64 system, it's not.

I hope that clears up the issue.

- Julian
Received on 2017-11-23 12:17:21 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.