subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: svnserve with corrupt timestamps and malformed text representation
Date Tue, 04 Jan 2011 12:39:42 GMT
René Hjortskov Nielsen wrote on Tue, Jan 04, 2011 at 13:08:51 +0100:
> Hopefully this is useful information for someone :)

It's useful, yes.  You could pass this information directly to the APR
project: http://apr.apache.org/ should identify the mailing list you
need.

Thanks,

Daniel



René Hjortskov Nielsen wrote on Tue, Jan 04, 2011 at 13:08:51 +0100:
> Thanks for your input.
>
> I ended up debugging the subversion and apr code and found the solution.
>
> I corrected the timestamps by making some typecasts in  
> subversion-1.6.13/apr/time/unix/time.c:
> "
> APR_DECLARE(apr_time_t) apr_time_now(void)
> {
>    struct timeval tv;
>    gettimeofday(&tv, NULL);
>    // RHN: Need to typecast these in order to preserve 8 byte result,  
> otherwise it gets treated as 4 bytes.
>    return tv.tv_sec * (long long)APR_USEC_PER_SEC + (long long)tv.tv_usec;
>    // return tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec;
> }
> "
>
> Since we are multiplying with 1000000 here, we get a huge number for  
> instance
> apr_time_t   = 1294141942240251 as long long and with my typecasts
> binary           :  100 10011001 00000011 11100110 11000001 10010011  
> 11111011
> apr_time_t   :  -423521285 without typecasts, apparently represented as a 
> 4 byte type which can hold 4294967295 as the largest positive number.
> 4294967295 = 11111111 11111111 11111111 11111111
>
> Hence it should be safe to add the above typecasts to the trunk in the 
> apr code, because the needed size of the timestamp will be the same on a 
> 32-bit machine aswell on a 64-bit machine.
>
> However, this only fixed the timestamp generation and not the string  
> generation for the --log-file directive.
>
> Thus removing the error:
> "
> Bogus date
> "
>
> The solution here was also easy and I found that the apr.h file generated 
> by configure had the wrong output form:
> "
> /* And APR_OFF_T_FMT */
> #define APR_OFF_T_FMT "ld"
> //?? APR_INT64_T_FMT
>
> /* And APR_PID_T_FMT */
> #define APR_PID_T_FMT "ld"
> //?? APR_INT64_T_FMT
> "
>
> Basically, I changed the formatters from lld to ld. Please note that I 
> had to do the same for APR_OFF_T_FMT, which also was formatted wrong.
>
> This fixes the svn import, commit or mkdir error stating:
> "
> svn: Corrupt node-revision '0.0.t0-1'
> svn: Malformed text representation offset line in node-rev
> "
>
> I'm not sure that these apr.h changes are universal changes, mainly due 
> to off_t being defined as 4 bytes and sometimes as 8 bytes.
>
> Hopefully this is useful information for someone :)
>
> Best regards,
> René
>
> -----Oprindelig meddelelse----- From: Daniel Shahaf
> Sent: Saturday, January 01, 2011 12:38 PM
> To: RenéHjortskov Nielsen
> Cc: users@subversion.apache.org
> Subject: Re: svnserve with corrupt timestamps
>
> René Hjortskov Nielsen wrote on Sat, Jan 01, 2011 at 09:51:57 +0100:
>> I’ve cross compiled subversion 1.6.15 on my i686 to the target system  
>> armv4l (product ib-nas3221-b).
>>
>> Everything seems to work, I can work with my old repository which has 
>> been moved to the target system.
>>
>> However, when I do a commit through svnserve running on the target I 
>> get the commonly known and unresolved “bug” Bogus date.
>>
>> I have tested that this is not the case when using the repository with 
>> my client (TortoiseSVN) directly, i.e. file protocol.
>>
>> I have noticed that all svnserve timestamps are bad, even in the 
>> logfile when running svnserve with –log-file.
>>
>> Here are some sample logfile timestamps from svnserve:
>> 5191 1969-12-31T23:57:53.-414901Z 192.168.5.4 xx newrepo open 2  
>> cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo 
>> log-revprops) / SVN/1.6.15%20(r1038135) -
>> 5191 1969-12-31T23:57:53.-404901Z 192.168.5.4 xx newrepo get-latest-rev
>> 5191 1969-12-31T23:57:53.-394901Z 192.168.5.4 xx newrepo reparent /
>> 5191 1969-12-31T23:57:53.-394901Z 192.168.5.4 xx newrepo stat /@0
>> 5192 1969-12-31T23:57:53.-334901Z 192.168.5.4 xx newrepo open 2  
>> cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo 
>> log-revprops) / SVN/1.6.15%20(r1038135) -
>>
>> Date on my target server with date command was:
>> Sat Dec  31 14:03:57 CST 2010
>>
>> On a commit through svnserve the same bogus dates are written 
>> everywhere, rendering the repository unsuable, i.e. 
>> newrepo/db/revprops/0/1
>>
>> I am woundering if this is a 32-/64-bit issue, even though both my i686 
>> build system and the armv4l target system are 32-bit editions.
>>
>
> The date is parsed into an apr_time_t, which is a 64-bit type
> (in APR 1.4.2).
>
>> Exactly how is the date supposed to be generated in svnserve?
>>
>
> During commits, the client sends the would-be revprops to the server.
> But the server overrides svn:date and svn:author and computes them
> itself.
>
> At some point, all revprops undergo validation (see validate_prop() in
> subversion/libsvn_repos/fs-wrap.c), one of those validations being that
> svn:date's value is in the expected machine-readable format:
>
> % svn pg --revprop -rHEAD svn:date  
> http://svn.apache.org/repos/asf/subversion
> 2011-01-01T11:33:37.147038Z
>
>> Currently my understanding is that dates are mapped back and forth from 
>> human readable formats to machine format, thus I suspect that this 
>> could be the source of the problem.
>>
>> Unfortunately I do not have the time to start writing debug code to  
>> isolate the problem at hand and was hoping that someone with enough  
>> insight could provide the debug code, which I happily will recompile 
>> and test.
>>
>> Best regards and a happy new year,
>> René 
>

Mime
View raw message