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
you.
>
> 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