Johan Corveleyn wrote:
> Stefan,
>
> On Tue, Aug 31, 2010 at 10:07 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>
>> Some additional info:
>> - I couldn't reproduce the crash with a narrow range. Not even 90000:0 would
>> crash it (right after startup).
>> - BUT: if after 90000:0 I run log without -r arguments, I get an error on
>> the client side:
>> [[[
>> ..\..\..\subversion\svn\log-cmd.c:746: (apr_err=160013)
>> ..\..\..\subversion\libsvn_client\log.c:606: (apr_err=160013)
>> ..\..\..\subversion\libsvn_repos\log.c:1474: (apr_err=160013)
>> svn: File not found: revision 90799, path '?\239'
>> ..\..\..\subversion\libsvn_repos\log.c:372: (apr_err=160013)
>> svn: File not found: revision 90799, path '?\239'
>> ..\..\..\subversion\libsvn_fs_fs\tree.c:3313: (apr_err=160013)
>> svn: File not found: revision 90799, path '?\239'
>> ..\..\..\subversion\libsvn_fs_fs\tree.c:3313: (apr_err=160013)
>> svn: File not found: revision 90799, path '?\239'
>> ..\..\..\subversion\libsvn_fs_fs\tree.c:3159: (apr_err=160013)
>> svn: File not found: revision 90799, path '?\239'
>> ..\..\..\subversion\libsvn_fs_fs\tree.c:668: (apr_err=160013)
>> svn: File not found: revision 90799, path '?\239'
>> ]]]
>> - This also happens when the first run is 60000:0 or even 42000:0. If the
>> first run is 41000:0, then the second run doesn't get the client-side error,
>> but the server crashes on the expected spot (after rev 42100).
>> - The above client-side error also happens if the second run is 96000:90000
>> instead of a log without -r argument.
>> - However, if I run "log -r96000:90000" right after startup, no problem.
>> - Other than that, it crashes reproducibly after 42100 if I run log with no
>> -r arguments right after startup.
>>
>
> I experimented some more. There must be something strange with that
> revision 90799 that also causes the client-side error.
>
> Some log runs immediately after startup:
> - "svn log -r90798:0 svn://localhost/path/bigfile.xml": no crash
> - "svn log -r90799:0 svn://localhost/path/bigfile.xml": crash (last
> log entry: 42104 (one before 42100 of the "regular" crash))
> - "svn log -r90921:0 svn://localhost/path/bigfile.xml": crash (last
> log entry: 42130 (two before 42100 of the "regular" crash)). r90921 is
> one before 90799.
> - "svn log -r90998:0 svn://localhost/path/bigfile.xml": crash (last
> log entry: 42149 (three before 42100 of the "regular" crash)). r90998
> is two before 90799.
> - "svn log svn://localhost/path/bigfile.xml": still crashes
> consistently with last log entry 42100.
>
> Still r90799 itself seems a very normal commit, with only text
> modifications to bigfile.xml.
>
> One more note: the repository was once created by converting our CVS
> repository with cvs2svn (it's an old conversion that we did as an
> experiment, after which we did the real conversion; but I still use
> the old converted repo to test things). I just now notice that we did
> that old conversion with the "cvs-revnum" option, i.e. updating the
> cvs2svn:cvs-rev property on every commit, to make it contain the cvs
> revision number of the file. So every commit also contains prop
> changes. Probably not relevant, but you never know :-).
>
Hm. From all you write it seems that there is some key collision
going on here: Assuming that the stack traces were made *with*
the debugging patches in place, we can be reasonably sure that
* the cached data itself did not get corrupted
(else, checksums would differ)
* the serialization code works as well
(otherwise, we should see the assertion being triggered by the
debug code in _set() but we still see it for _get() only)
The only way to get closer to understanding the nature of the
problem, I've added extensive logging code to the cache.
Please run "svnserve -M1000 -d --forground -r ... > svnserve.log",
zip the log file after the programm crashed & got terminated and
send it to me directly.
-- Stefan^2.
Received on 2010-09-06 02:11:07 CEST