another midx error, unclear if related

[Greg Troxel]

bup 0.33.10 both sides. repo is big and has two midx, 533M, 507M.
Apparently correctly reflected in client's index cache. backup is -r
over ssh.

client has printed:

Exception ignored in: <function PackMidx.__del__ at 0x72bbc0f775b0>
Traceback (most recent call last):
File "/usr/pkg/lib/bup/bup/midx.py", line 107, in __del__
assert self.closed
AssertionError:
Exception ignored in: <function mmap.__del__ at 0x72bbc135fa90>
Traceback (most recent call last):
File "/usr/pkg/lib/bup/bup/io.py", line 60, in __del__
assert self._bup_closed
AssertionError:

Backup is still going, limiting factor is CPU on the bup server:

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
3221 gdt 28 0 9606M 9509M CPU/1 12:10 97.90% 97.90% bup

Free RAM is ok.



This is more or less just shared in the hopes that it's more useful than
time consuming as we seem to have some midx-related problems and my
impression is that nobody is really clear on exactly what or if all the
issues are related.

[Rob Browning]

Greg Troxel <g...@lexort.com> writes:

> bup 0.33.10 both sides. repo is big and has two midx, 533M, 507M.
> Apparently correctly reflected in client's index cache. backup is -r
> over ssh.

If you have time and the space, it'd be interesting to see if main also
has the problem(s), but for now I'd only do that on copies of the
data.

--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4