> > Has anyone else noticed a client memory leak when using > > svn:externals in the 1.7.3 client? > > > > We have a large project with tens of thousands of externals. > > When checked out with a 1.6 client, it uses 150MB of memory. > > When checked out with a 1.7 client it uses >1.5GB of memory. > > Same memory issue occurs with an update. > > > > I'm still putting a test script together to show the behavior, > > but it appears to be leaking 400k per external when I > > watch task manager in Windows. > > > > We first observed this with TortoiseSVN, but the same > > behavior exists with the command line client. > > > > I was hoping a developer may have valgrind setup > > and could catch this easier. > > > > Server version does not matter, this occurs with > > both a 1.6.17 and a 1.7.3 server when a 1.7.3 > > client is used. Does not occur if a 1.6.17 client > > is used. All testing was done with neon, but > > that is only because serf does not complete > > the test. > > > > I'm in the middle of creating the script to > > create the test case, but was hoping > > to get a fix into 1.7.4, so I'm posting this early. > > It might already be fixed: I see a leak with 1.7.x@r1293812 but r1293813 > appears to fix it.
Definitely not fixed, at least for https:// externals. This is what I did: svn co https://svn.apache.org/repos/asf/subversion/branches/1.7.x svn_17x cd svn_17x sh get-deps.sh sh autogen.sh ./configure --prefix=/usr/lfs/v0/apps/subversion/1.7.x --without-apxs --without-swig --without-sasl --disable-mod-activation --enable-maintainer-mode --enable-debug make all make install (This didn't build neon correctly, but might help diagnose the serf failure.) ./svn --version svn, version 1.7.4-dev (under development) compiled Feb 28 2012, 09:26:45 Copyright (C) 2012 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme subversion/svn/checkout-cmd.c:168: (apr_err=104) subversion/libsvn_client/checkout.c:229: (apr_err=104) subversion/libsvn_client/update.c:551: (apr_err=104) subversion/libsvn_client/update.c:412: (apr_err=104) subversion/libsvn_ra_serf/update.c:2402: (apr_err=104) subversion/libsvn_ra_serf/update.c:2402: (apr_err=104) svn: E000104: Error retrieving REPORT (104): Connection reset by peer running under valgrind gives a summary of: ==1746== LEAK SUMMARY: ==1746== definitely lost: 90,112 bytes in 7 blocks ==1746== indirectly lost: 1,413,797 bytes in 44,850 blocks ==1746== possibly lost: 199 bytes in 6 blocks ==1746== still reachable: 33,364 bytes in 2,250 blocks ==1746== suppressed: 0 bytes in 0 blocks ==1746== ==1746== For counts of detected and suppressed errors, rerun with: -v ==1746== ERROR SUMMARY: 505 errors from 143 contexts (suppressed: 66 from 8) And that is before it really started checking out any externals... The complete valgrind log is huge, so I didn't want to send it to the list. I'll also work on updating serf and getting neon working in the build so we can debug the actual svn:externals memory leak. Kevin R.
