Memory Consumption...

So after a night of reading and running the code in a debugger, I
finally gave up and turned on the apr_pool debugging. Then the problem
went away. I hate bugs like that.

Adding this:

#define APR_POOL_DEBUG 1

to apr/include/apr_pools.h

right after the comment and before the preprocessor stuff:

  * When no debug level was specified, assume general debug mode.
  * If level 0 was specified, debugging is switched off
  */

  <-- insert here...

#if defined(APR_POOL_DEBUG)
#if (APR_POOL_DEBUG != 0) && (APR_POOL_DEBUG - 0 == 0)

fixes all of the memory consumption issues. Code runs like a champ
after that. I couldn't import even half of the linux-2.4.0 imported
into a repository with 300MB of VM it died from OOM, however, the max
memory consumption with that added is a little over 11M at the peak.

I have two binaries, one badSVN and svn. Both were created from:

make clean && make

run in the root of the tree. I have apr, neon and bdb softlinked from
the root of the repository. I had svn build everything for me as
described in the README file. The only difference between the two is
the debug flag on pools.

Sorry if anybody wasted too much time on my report earlier. I am too
tired right now to figure out what is broken with pools in APR. They
swap out a lot of guts when you turn debugging on so I imagine it will
be a trick to figure it out. Given I am not sure I understand all of
the fundamentals of the pool stuff, I'll leave it to the experts...

Oh, I have the version of APR from the CVS repository from Jan 30th I
believe. The neon and db are the versions listed in the README.

        Thanks,
                Kirby

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:03 2006