You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Akin, Klaus" <Kl...@infor.de> on 2005/06/22 11:02:10 UTC
AW: AW: This application has requested the Runtime to terminate i
t in an unusual way.
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
Klaus
-----Ursprüngliche Nachricht-----
Von: John Szakmeister [mailto:john@szakmeister.net]
Gesendet: Mittwoch, 22. Juni 2005 10:55
An: users@subversion.tigris.org
Betreff: Re: AW: This application has requested the Runtime to terminate it
in an unusual way.
On Wednesday 22 June 2005 04:29, Akin, Klaus wrote:
> Hallo,
>
> Thanks for your answer. You are right, it is an out of memory error.
> The memory of the process goes up to 2 GB (which is the upper bound for
> a Process on a win 32 machine), and than throws an out of memory error.
> The files, which I want to checkout have an amount of 400MB (without
> the .svn files). During the merge the memory is always increasing and
> never decreasing.
> Is there a memory leak in the svn client?
There could be a place where we aren't freeing the memory as early as we
can. I thought several developers chased most of these down... perhaps
we missed on though.
Can you generate a complete reproduction recipe? Starting from creating a
repository, to chewing up lots of memory? It doesn't have to fail, but
as long as we can see the memory grow unbounded, that will be sufficient.
It would greatly help to have such a recipe when chasing down this
problem.
Thanks!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.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 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
Re: AW: AW: This application has requested the Runtime to terminate i t in an unusual way.
Posted by John Szakmeister <jo...@szakmeister.net>.
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