This has started a few days ago. I don't know if this was triggered by a
multiprocessing change or an unrelated one.
On trunk:

test_multiprocessing
beginning 6 repetitions
123456
......
test_multiprocessing leaked [277, 277, 277] references, sum=831

On py3k:

test_multiprocessing
beginning 6 repetitions
123456
......
test_multiprocessing leaked [229, 229, 229] references, sum=687

AFAIK; I haven't changed anything which would introduce refleaks in the 
code. So, it's going to be a matter of chasing down all of the changes 
since the refleaks popped up and see which one triggered it.

This started just after r76438, which is an additional test for
multiprocessing.  Given build delays this is only a correlation not a
definite cause, but it is suspicious.

> R. David Murray <rdmurray@bitdance.com> added the comment:
> 
> This started just after r76438, which is an additional test for
> multiprocessing.  Given build delays this is only a correlation not a
> definite cause, but it is suspicious.

I just checked, it was indeed introduced by r76438.

Well, that's alarming. I'll back that out for now - I'm fairly disturbed 
it introduced leaks that bad.

I've backed it out on trunk and py3k. I've reopened the original bug to 
debug the refleak caused by the test.

I haven't looked at the test, but is it possible that the logging module
is creating state that isn't being cleaned up after the test completes?
 Test refleaks don't always mean refleaks in the underlying C code.