You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Szakmeister <jo...@szakmeister.net> on 2005/06/23 10:33:35 UTC
Re: AW: AW: This application has requested the Runtime to terminate i t in an unusual way.
On Wednesday 22 June 2005 07:02, Akin, Klaus wrote:
> Hi,
>
> The recipe to get a large memory usage on the svn client:
>
> -- first check out some data for example:
> svn co http://svn.collab.net/repos/svn/trunk subversion
> -- delete all .svn files in this folder
>
> -- create the repository
> svnadmin create memoryleak
> -- make it general writeable
>
> --start the server
> start svnserve -d -r .
>
> -- import the data to folder subversion
> svn import subversion svn://<machine>/memoryLeak/subversion/ -m
> "import" -- create an empty dir
> svn mkdir svn://<machine>/memoryLeak/empty -m "creating empty dir"
> -- checkout the empty folder
> svn co svn://<machine>/memoryLeak/empty test
> -- merge
> svn merge svn://<machine>/memoryLeak/empty
> svn:// <machine>/memoryLeak/subversion/ test
>
> During the merge the process is increasing to 60MB. It is never
> decreasing during merge. The data in the test folder is about 53MB.
Thanks, I was able to verify this on my Linux box as well (except it grew
to nearly 80MB). I made a couple of quick patches and it seemed to stop
at around 12.5MB. I'm running through the test suite and such right now.
But since this is in working copy code (which is notoriously complex),
I'll post it a patch on dev@ list later tonight. Hopefully, we can get
this in for the next release (but no guarantees as 1.2.1 is right around
the corner).
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [PATCH] Re: This application has requested the Runtime to terminate i t in an unusual way.
Posted by John Szakmeister <jo...@szakmeister.net>.
On Friday 24 June 2005 05:33, John Szakmeister wrote:
> On Thursday 23 June 2005 20:25, John Szakmeister wrote:
> [snip]
>
> > > Thanks, I was able to verify this on my Linux box as well (except
> > > it grew to nearly 80MB). I made a couple of quick patches and it
> > > seemed to stop at around 12.5MB. I'm running through the test
> > > suite and such right now. But since this is in working copy code
> > > (which is notoriously complex), I'll post it a patch on dev@ list
> > > later tonight. Hopefully, we can get this in for the next release
> > > (but no guarantees as 1.2.1 is right around the corner).
> >
> > Here's the patch I was using. I'm posting here to the dev@ list in
> > hopes that someone with a little more knowledge behind the merge
> > operation can see if this is acceptable. From what I can tell, a
> > number of operations were using the pool in the merge baton, but they
> > didn't need that long of a lifetime. So I switched them to using the
> > subpool instead. It passes 'make check'.
>
> Whoops! I forgot to attach the patch (Thanks David). Here it is.
I committed this patch in r15233 on trunk/.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Re: This application has requested the Runtime to terminate i t in an unusual way.
Posted by John Szakmeister <jo...@szakmeister.net>.
This was sent on the users@ list about the patch as well...
-John
On Thursday 30 June 2005 08:51, Akin, Klaus wrote:
> Hello,
>
> I've tried the patch from John and it works great.
> Before that patch, I've done a merge and it took over 2GB memory and
> then causes a crash. With it, it took about 60MB.
> Great job! Thanks John.
> Is there a chance to get this patch in the trunk and so in the next
> release?
>
> Cioa
> Klaus
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Re: This application has requested the Runtime to terminate i t in an unusual way.
Posted by John Szakmeister <jo...@szakmeister.net>.
On Thursday 23 June 2005 20:25, John Szakmeister wrote:
[snip]
> >
> > Thanks, I was able to verify this on my Linux box as well (except it
> > grew to nearly 80MB). I made a couple of quick patches and it seemed
> > to stop at around 12.5MB. I'm running through the test suite and
> > such right now. But since this is in working copy code (which is
> > notoriously complex), I'll post it a patch on dev@ list later
> > tonight. Hopefully, we can get this in for the next release (but no
> > guarantees as 1.2.1 is right around the corner).
>
> Here's the patch I was using. I'm posting here to the dev@ list in
> hopes that someone with a little more knowledge behind the merge
> operation can see if this is acceptable. From what I can tell, a
> number of operations were using the pool in the merge baton, but they
> didn't need that long of a lifetime. So I switched them to using the
> subpool instead. It passes 'make check'.
Whoops! I forgot to attach the patch (Thanks David). Here it is.
-John
Re: [PATCH] Re: This application has requested the Runtime to terminate i t in an unusual way.
Posted by David Faure <fa...@kde.org>.
On Friday 24 June 2005 02:25, John Szakmeister wrote:
> Here's the patch I was using.
You forgot to attach it.
Strange, since you're using KMail-1.7.1 which detects "patch" in the mail and reminds you to attach it ;-)
--
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [PATCH] Re: This application has requested the Runtime to terminate i t in an unusual way.
Posted by John Szakmeister <jo...@szakmeister.net>.
On Thursday 23 June 2005 20:25, John Szakmeister wrote:
[snip]
> >
> > Thanks, I was able to verify this on my Linux box as well (except it
> > grew to nearly 80MB). I made a couple of quick patches and it seemed
> > to stop at around 12.5MB. I'm running through the test suite and
> > such right now. But since this is in working copy code (which is
> > notoriously complex), I'll post it a patch on dev@ list later
> > tonight. Hopefully, we can get this in for the next release (but no
> > guarantees as 1.2.1 is right around the corner).
>
> Here's the patch I was using. I'm posting here to the dev@ list in
> hopes that someone with a little more knowledge behind the merge
> operation can see if this is acceptable. From what I can tell, a
> number of operations were using the pool in the merge baton, but they
> didn't need that long of a lifetime. So I switched them to using the
> subpool instead. It passes 'make check'.
Whoops! I forgot to attach the patch (Thanks David). Here it is.
-John
[PATCH] Re: This application has requested the Runtime to terminate i t in an unusual way.
Posted by John Szakmeister <jo...@szakmeister.net>.
On Thursday 23 June 2005 06:33, John Szakmeister wrote:
> On Wednesday 22 June 2005 07:02, Akin, Klaus wrote:
> > Hi,
> >
> > The recipe to get a large memory usage on the svn client:
> >
> > -- first check out some data for example:
> > svn co http://svn.collab.net/repos/svn/trunk subversion
> > -- delete all .svn files in this folder
> >
> > -- create the repository
> > svnadmin create memoryleak
> > -- make it general writeable
> >
> > --start the server
> > start svnserve -d -r .
> >
> > -- import the data to folder subversion
> > svn import subversion svn://<machine>/memoryLeak/subversion/ -m
> > "import" -- create an empty dir
> > svn mkdir svn://<machine>/memoryLeak/empty -m "creating empty dir"
> > -- checkout the empty folder
> > svn co svn://<machine>/memoryLeak/empty test
> > -- merge
> > svn merge svn://<machine>/memoryLeak/empty
> > svn:// <machine>/memoryLeak/subversion/ test
> >
> > During the merge the process is increasing to 60MB. It is never
> > decreasing during merge. The data in the test folder is about 53MB.
>
> Thanks, I was able to verify this on my Linux box as well (except it
> grew to nearly 80MB). I made a couple of quick patches and it seemed
> to stop at around 12.5MB. I'm running through the test suite and such
> right now. But since this is in working copy code (which is notoriously
> complex), I'll post it a patch on dev@ list later tonight. Hopefully,
> we can get this in for the next release (but no guarantees as 1.2.1 is
> right around the corner).
Here's the patch I was using. I'm posting here to the dev@ list in hopes
that someone with a little more knowledge behind the merge operation can
see if this is acceptable. From what I can tell, a number of operations
were using the pool in the merge baton, but they didn't need that long of
a lifetime. So I switched them to using the subpool instead. It passes
'make check'.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
[PATCH] Re: This application has requested the Runtime to terminate i t in an unusual way.
Posted by John Szakmeister <jo...@szakmeister.net>.
On Thursday 23 June 2005 06:33, John Szakmeister wrote:
> On Wednesday 22 June 2005 07:02, Akin, Klaus wrote:
> > Hi,
> >
> > The recipe to get a large memory usage on the svn client:
> >
> > -- first check out some data for example:
> > svn co http://svn.collab.net/repos/svn/trunk subversion
> > -- delete all .svn files in this folder
> >
> > -- create the repository
> > svnadmin create memoryleak
> > -- make it general writeable
> >
> > --start the server
> > start svnserve -d -r .
> >
> > -- import the data to folder subversion
> > svn import subversion svn://<machine>/memoryLeak/subversion/ -m
> > "import" -- create an empty dir
> > svn mkdir svn://<machine>/memoryLeak/empty -m "creating empty dir"
> > -- checkout the empty folder
> > svn co svn://<machine>/memoryLeak/empty test
> > -- merge
> > svn merge svn://<machine>/memoryLeak/empty
> > svn:// <machine>/memoryLeak/subversion/ test
> >
> > During the merge the process is increasing to 60MB. It is never
> > decreasing during merge. The data in the test folder is about 53MB.
>
> Thanks, I was able to verify this on my Linux box as well (except it
> grew to nearly 80MB). I made a couple of quick patches and it seemed
> to stop at around 12.5MB. I'm running through the test suite and such
> right now. But since this is in working copy code (which is notoriously
> complex), I'll post it a patch on dev@ list later tonight. Hopefully,
> we can get this in for the next release (but no guarantees as 1.2.1 is
> right around the corner).
Here's the patch I was using. I'm posting here to the dev@ list in hopes
that someone with a little more knowledge behind the merge operation can
see if this is acceptable. From what I can tell, a number of operations
were using the pool in the merge baton, but they didn't need that long of
a lifetime. So I switched them to using the subpool instead. It passes
'make check'.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org