fs memory leak.

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

OK, folks, Karl and I just sat down and made a list of "symptoms" that
have to do with memory-leak bugs.

  (Ben)

    * when I run 'fs-test 23' (merge) or 'fs-test 24' (delta_dir), and
      even when I commit, I see kernel (or libc) errors about memory
      being overly-freed: fs-test in free(): warning: chunk is already
      free.

    * when I import a large tree into a repository, all swap space
      gets sucked up.  (I can literally watch it vanish in 'top').
      Making the fs-commit editor create/free subpools had no effect.

  (Karl)

    * when he runs fs-test 23 and 24 *together*, his system crawls,
      all the way into a hang.  The kernel eventually kills the
      process when he runs out of swap.

    * inside fs-test #24 is a double-loop; Karl did an experiment: in
      the interior of this loop, Karl creates a subpool and uses it to
      get an editor.  Then he drives the editor using a global pool,
      and then frees the subpool.  Somewhere he's getting a segfault.


Using our Deductive Skillz, we notice that *all* of these problems
have something to do with the filesystem.  In fact, the only symptom
above that uses any client-side code at all is the 'import' command;
but that command uses no pools at *all* to walk over a directory using
apr_file_* commands!

Therefore, we now officially suspect a serious memory leak deep within
the bowels of libsvn_fs (i.e. *not* in the commit editor.)  It's also
not likely to be in db3, since... well, since it's very mature
software.

Off we go to hunt this down.