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

Re: svn commit: r990537 - /subversion/branches/performance/subversion/libsvn_subr/svn_temp_serializer.c

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Tue, 31 Aug 2010 00:36:57 +0200

Johan Corveleyn wrote:
> On Mon, Aug 30, 2010 at 12:05 PM, Stefan Fuhrmann
> <stefanfuhrmann_at_alice-dsl.de <mailto:stefanfuhrmann_at_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.
Received on 2010-08-31 00:38:03 CEST

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.