"bzr multi-pull" consumes excessive memory

[Chris Halse Rogers]

I have a shared repository with 6 branches under it, and a couple of non-branch directories. Running bzr multi-pull from bzr.dev in this directory eventually consumes over 1000Mb of resident memory.

Interestingly, this only occurs when the "Packaging" (directory listing attached) directory is in the current directory. When this directory exists, bzr rapidly consumes ~600MB worth of resident memory before any output is displayed (backtrace at this point attached), and then more slowly goes on to consume another 400MB or so over the rest of the operation.

It seems like there may be two bugs here: bzr multi-pull appears to have a monotone increasing memory footprint, and does something crazy when it encounters the Packaging directory.

I'm not sure what's special about the Packaging directory; I've tried making a directory with many subdirectories, a directory with many files in it, and a directory with many files containing a '~' character, and a directory containing many links, none of which seemed to cause bzr to exhibit pathological behaviour.

The packaging directory is ~100Mb, and can be provided on request, as can the entire repository+trees.

bzr version info:
Bazaar (bzr) 1.7dev
  from bzr checkout /home/raof/Devel/bzr/bzr.dev
    revision: 3664
    revid: <email address hidden>
    branch nick: bzr.dev
  Python interpreter: /usr/bin/python 2.5.2
  Python standard library: /usr/lib/python2.5
  bzrlib: /home/raof/Devel/bzr/bzr.dev/bzrlib
  Bazaar configuration: /home/raof/.bazaar
  Bazaar log file: /home/raof/.bzr.log

[John A Meinel (jameinel)]

If I was guessing, I would say the problem is multi-pull trying to find branches that need to be synced. I believe at one point it would try to open every path that it found. It could certainly be that our Branch objects are creating a reference cycle, so they aren't getting garbage collected correctly. So having lots of files and directories is triggering the poor behavior.

A few fixes would be in order:

1) Try to make multi-pull smarter about not grabbing a branch for every object, I think there are a few valid reasons for doing so, so I would be cautions with a specific fix. (For example, you may have SVN directories and the bzr-svn plugin installed, so multi-pull would probably update them as well.)

2) Figure out why memory is increasing without being freed. Is it a reference cycle, or is it something that multi-pull is caching and not releasing.

[Andrew Bennetts (spiv)]

I've noticed that having some versions of the bzr-svn plugin installed will cause multi-pull to consume excessive memory. (It seems that in some situations the svn bindings leak memory on failed attempts to open directories as SVN directories).

I'm not sure if this is true with the current trunk of bzr-svn, but it might be worth trying to see if you can reproduce this without bzr-svn installed (assuming that you do have it installed).

(I think there may be other bug reports on the same topic; search for bugs involving "find_branches" perhaps?)

[Chris Halse Rogers (raof)]

Good thinking; after removing the bzr-svn plugin, I still see monotone increasing memory useage, but it reaches a peak of 27MB resident, rather than 1000MB resident.

This was with bzr-svn 0.4.11-1, the version in Intrepid. Time to try with bzr-svn trunk, I guess.

[Robert Collins (lifeless)]

 affects bzr-svn

[Jelmer Vernooij (jelmer)]

I think ~27 Mb of memory usage is reasonable, the memory leak really was in bzr-svn and that bit has been fixed.