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

Re: Subversion 0.24.2 released.

From: Kevin Pilch-Bisson <kevin_at_pilchie.homeip.net>
Date: 2003-06-19 12:03:22 CEST

On Thu, Jun 19, 2003 at 11:46:52AM -0500, Kirby C. Bohling wrote:
> On Thu, 2003-06-19 at 11:37, Han The Man wrote:
> > > > I was under the impression that they aren't leaks but rather
> > > > inefficient pool usage.
> > >
> > >Ha! What's the difference? The phrases "memory leak" and
> > >"inefficient pool usage" both mean the same thing: that somewhere
> > >you're allocating memory, but not freeing it when you should.
> >
> > I'd say there's a big difference. Inefficent pool usage indicates that the
> > memory will be reclaimed after the operation has completed. A leak does not.
> > Or am I wrong?
> Yeah, but if the inefficient usage is in the top pool, or it's so
> inefficient in a high level pool that you can't finish the operation,
> they are functionaly equivilent. At least in UNIX, as a general rule,
> you can't leak memory permanently with malloc or brk, when your process
> dies, all the resources are freed (shared memory might not be freed).

Should be the same on Win32.
> Subversion in my experience frequently has lots of problems with pool
> usage. As I recall that was the first mail I sent to the list (that and
> asking why the BDB took up so much space relative to the CVS repository
> I was converting).
> Wonder if APR has a way you can tell it, never give me more then X bytes
> of memory, or have APR keep track of peak memory usage, so it could be
> regression tested for. The problem is that the memory regression test
> might involve a lot of files and take a lot of time.

Sure: Compile apr with pool debugging turned on. You'll get tons of stats
about the total memory usage, but you might need a script to parse them for
> Kirby

Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 19 19:07:24 2003

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.