Johan Corveleyn wrote:
On Mon, Aug 30, 2010 at 12:05 PM, Stefan Fuhrmann <stefanfuhrm...@alice-dsl.de <mailto:stefanfuhrm...@alice-dsl.de>> wrote:


        Is there any way I can find more information about this
        failure, so I
        can help you diagnose the problem?

    In fact there is. Just some questions:

    * You are the only one accessing the server and you use
     a single client process?


Yes. All on the same machine actually (my laptop). Accessing the server with svn://localhost.
    * Does it happen if you log / blame the file for the first time
     and no other requests have been made to the server before?


Yes
    * Does a command line "svn log" produce some output
     before the crash? If so, is there something unusual happening
     around these revisions (branch replacement or so)?


Yes. Running "svn log svn://localhost/trunk/some/path/bigfile.xml" yields 969 of the 2279 log entries. From r95849 (last change to this file) down to r42100. Then it suddenly stops.

I've checked r42100 with "log -v", and it only mentions text modification of bigfile.xml. Same goes for the previous and next revisions in which bigfile.xml was affected (r42104 and r42042).

Good, we should then be able to find the root cause
since this is a simple setup and the crash is deterministic.

Have you tried svn log with a range like -r42104:42042
(or larger)? Perhaps, we can narrow it down to a single
revision (probably "svn log -r42042").

    Also, please verify that the crash gets triggered if the server is
    started
    with the following extra parameters:

    * -c0 -M0 -F0


No crash
That disabled all membuffer as well as the file handle caches
but the serialization code is still active.
    * -c0 -M0


No crash
So, its not an issue with file handles kept open, positions
not being tracked properly or something.
    * -c0 -M1500 -F0


Crash (actually I did it with -M1000, because M1500 would give me an "Out of memory" immediately).
Good. "-c0" is just the standard setup I use and it does
not prevent the crash. -M1000 is certainly large enough
to keep all data in cache, i.e. the entry eviction / cache
compaction code won't get triggered.
    * -c0 -M1500


Crash (with -M1000 that is)
Again, the file handle cache has no impact.

-- Stefan^2.

Reply via email to