[prev in list] [next in list] [prev in thread] [next in thread]
List: subversion-dev
Subject: Re: Error E140001: Sum of subblock sizes larger than total block content length
From: Ronald Taneza <ronald.taneza () gmail ! com>
Date: 2017-11-23 12:56:57
Message-ID: CABWospkiMmh-VAQxqRCHP=HRwNJHjPrTosOXDp1R0NHA3uh5CA () mail ! gmail ! com
[Download RAW message or body]
Hi Julian,
> 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.)
Ok, that explains it. I did not know that 'long' is 32 bits on 64-bit
Windows. Most of my experience with C is on embedded systems where we use
specific integer sizes (like C99 stdint.h types).
Thanks!
Regards,
Ronald
On Thu, Nov 23, 2017 at 12:17 PM, Julian Foad <julianfoad@apache.org> wrote:
> 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.)
>
> ( https://stackoverflow.com/questions/384502/what-is-the-bit-
> size-of-long-on-64-bit-windows#384672 )
>
> 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/question
>> s/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
>
[Attachment #3 (text/html)]
<div dir="ltr"><div>Hi Julian,</div><div><br></div><div>> This bug occurred \
because the "%ld" format and/or the 'long' data type were 32-bit. \
This is indeed the case:<br>> On 64-bit Windows, 'long' is a 32-bit type \
(and 'long long' is 64-bit; on most other platforms both are \
64-bit.)</div><div><br></div><div>Ok, that explains it. I did not know that \
'long' is 32 bits on 64-bit Windows. Most of my experience with C is on \
embedded systems where we use specific integer sizes (like C99 stdint.h \
types).</div><div><br></div><div>Thanks!</div><div><br></div><div>Regards,</div><div>Ronald</div><div><br></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 23, 2017 at 12:17 PM, \
Julian Foad <span dir="ltr"><<a href="mailto:julianfoad@apache.org" \
target="_blank">julianfoad@apache.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span>Ronald Taneza wrote:<br> <blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
Hi Julian,<br>
<br>
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.<br> \
</blockquote> <br></span>
It should be.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
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.<br> <br>
We are using Subversion Edge 5.2.2 (Windows 64-bit) on a Windows Server 2012 (64-bit) \
OS.<br> </blockquote>
<br></span>
This bug occurred because the "%ld" format and/or the 'long' data \
type were 32-bit. This is indeed the case:<br> <br>
On 64-bit Windows, 'long' is a 32-bit type (and 'long long' is \
64-bit; on most other platforms both are 64-bit.)<br> <br>
( <a href="https://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows#384672" \
target="_blank" rel="noreferrer">https://stackoverflow.com/ques<wbr>tions/384502/what-is-the-bit-<wbr>size-of-long-on-64-bit-windows<wbr>#384672</a> \
)<span><br> <br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
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: <a \
href="https://superuser.com/questions/358434/how-to-check-if-a-binary-is-32-or-64-bit-on-windows" \
target="_blank" rel="noreferrer">https://superuser.com/question<wbr>s/358434/how-to-check-if-a-<wbr>binary-is-32-or-64-bit-on-<wbr>windows</a>).<br>
<br>
You mentioned:<br>
<br>
> SVN_ERR(svn_stream_printf(eb-><wbr>stream, pool,<br>
<wbr> \
SVN_REPOS_DUMPFILE_CONTENT_LEN<wbr>GTH<br> ": %ld\n\n",<br>
(unsigned long)info->size +<br>
propstring->len));<br>
<br>
> info->size is apr_off_t ... probably 64 bits on most systems.<br>
> propstring->len is apr_size_t ... probably 64 bits on most systems.<br>
</blockquote>
<br></span>
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.<br> <br>
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.<span><br> <br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
> 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.<br> </blockquote>
<br></span>
When I wrote that, I was assuming a 32-bit architecture.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
On a 64-bit system where unsigned long is uint64:<br>
</blockquote>
<br></span>
On a standard Windows-64 system, it's not.<br>
<br>
I hope that clears up the issue.<span class="HOEnZb"><font color="#888888"><br>
<br>
- Julian<br>
</font></span></blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic