fs memory leak.

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.
Received on Sat Oct 21 14:36:26 2006