OK, folks, Karl and I just sat down and made a list of "symptoms" that
have to do with memory-leak bugs.
* 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
* 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.
* 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
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
Off we go to hunt this down.
Received on Sat Oct 21 14:36:26 2006