test_multiprocessing is producing tracebacks and hanging on py3k trunk.
 I think this started happening fairly recently, as it seemed to work in
one not-too-old checkout until I did an svn up and then it started
failing.  3.1 seems fine.  I've attached the tracebacks, including the
tracebacks I get when I ctrl-C to break the hang.  My system is Gentoo
Linux.

r75241 seems to be the cause.  Tests passes on r75240, but gives the
dict error and hang on r75241.

Adding gps - I haven't had a chance to grok the changes, and me getting to 
a fix is going to take a few.

It's passing for me on trunk/py3k at least on OS/X - I'm going to need to 
dredge up a linuxvm

Benjamin tried reverting the weakref patch, but that didn't fix it. 
Turns out the problem is the other patch in that merge, that adds saving
of the exception to AssertRaises.  Adding Kristjan as that was his patch.
(The tests pass with the weakref patch applied and the unittest patch
reverted, by the way.)

Interesting.  I don't have a linux machine to debug this.  My patch 
appears harmless enough.  We are only storing an exception _object_, not 
any tracebacks or such.
If this were happening on my windows machine I would put in breakpoints 
where the ignored assertion is being raised and find out what's going on.

It was a bad idea to revert the change, because we may now forget about
the problem rather than fix it.

It is likely that the "dictionary changed size during iteration" occurs
because a GC collection gets triggered during the iteration on the
weakdict. A GC collection can destroy some objects in that case because
keeping an exception around (which the unittest change does) usually
creates reference cycles through the frame's locals.

It seems that WeakValueDictionary.items() isn't very robust in py3k ;)
We probably need to add list-returning variants, e.g. a listitems()
method (and, probably, listkeys() and listvalues() too)?

The unittest only keeps an exception _object_ around, not the associated 
traceback.  There should be no frames and thus reference cycles associated 
with this.
I agree that the problem should be tackled, rather than swept under the 
carpet like a revert does.

> The unittest only keeps an exception _object_ around, not the associated 
> traceback.

In py3k, the traceback is attached to the exception (on the
__traceback__ attribute) ;)

I disagree about reverting it. We have this bug report, and that change
is sitting on the merge queue again...

I didn't realize that the traceback was attached to the exception object 
in py3k.  This makes the use of such objects more dangerous because of the  
circular references.  The recommended practice of
exc_type, exc_obj = sys.exc_info()[:2]
is precisely to avoid any "accidents" with the tracebacks.
See also http://mail.python.org/pipermail/python-dev/2005-
August/055251.html
So, can one just clear the __traceback__ member?  That would make sense 
for the unittests, but it would make this manifestation of a GC bug go 
into hiding again.

Kristján:
> So, can one just clear the __traceback__ member?

Yes, or use `exc_value.with_traceback(None)`.

If this is not ported by the time we get to a 2.7 or 3.2 release, I'd
like to back it out.

I can easily port it again, and remove the traceback from the exception.
But won't we be sweeping that GC problem under the carpet then?

Please note there's a patch in issue7105 to allow safer iteration of
weak dicts.

Ok, I ported the change again in revision 76238, removing the traceback 
from the stored exception object.

> Kristján Valur Jónsson <kristjan@ccpgames.com> added the comment:
> 
> Ok, I ported the change again in revision 76238, removing the traceback 
> from the stored exception object.

"versionchanged" should be 3.2, not 3.1.
Thanks!

Thanks. Fixed in revision 76239.

I don't know if it's your last change, but test_multiprocessing is now
hanging on all buildbots.

It is.  TestZZZNumberOfObjects hangs at r76238, and does not hang at
r76237 on my Gentoo Linux box.

It seems the error is different, though. This is what I get after Ctrl-C
(I omit the tracebacks from the other processes):

Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_multiprocessing.py",
line 1071, in test_number_of_objects
    refs = self.manager._number_of_objects()
  File "Z:\py3k\__svn__\lib\multiprocessing\managers.py", line 569, in
_number_of_objects
    conn = self._Client(self._address, authkey=self._authkey)
  File "Z:\py3k\__svn__\lib\multiprocessing\connection.py", line 134, in
Client
    c = SocketClient(address)
  File "Z:\py3k\__svn__\lib\multiprocessing\connection.py", line 253, in
SocketClient
    s.connect(address)
socket.error: [Errno 2] No such file or directory

Ok, the problem is that a finalizer calls _decref which tries to open an
XMLRPC connection (!) to an address on which nobody listens anymore.
Then stupid SocketClient (in multiprocessing.connection) loops endlessly
because it is designed to do so when it gets ECONNREFUSED.

(when you Ctrl-C, you don't see all this because it happens in a
finalizer, and only a terse message is displayed)

So there are two problems:
- why does test_multiprocessing think it should open an XMLRPC
connection to a closed endpoint
- why doesn't SocketClient have some kind of timeout rather than looping
stupidly

Yes, this is quite different.
After seeing this, I created issue 7314.
I didn't realize that it had anything to do with my patch but rather 
blamed it on my brand new windows 7.

> Yes, this is quite different.
> After seeing this, I created issue 7314.
> I didn't realize that it had anything to do with my patch but rather 
> blamed it on my brand new windows 7.

I don't think it has anything to do with your patch. While diagnosing
the problem, I noticed that adding some random print() lines would
sometimes make the problem disappear. So it is really timing-dependent
and your patch happens to trigger the right (or wrong ;-)) timing.

See my analysis from issue 7314:
The other processes are all waiting to ReadFile().  Maybe they have yet 
to run to the point where they open the socket to which the master 
process is trying to connect to.

The mystery is also: Why does the harmless act of setting an instance 
attribute on a context manager (and without any traceback) trigger this 
behaviour?

Ah, okay then.  Let's focus on solving 7414 then.

I don't think this is a blocker anymore. Kristján's patch has been
ported and the test_multiprocessing freezes have been "fixed" by adding
a timeout.
As for the original purpose of this ticket, issue7105 is still (part
of?) the answer.

I never seen this issue, can we close it?

#7105 has been fixed in Python 3, not in Python 2.7.

Okay, let's say it is fixed. Adding Richard to nosy so that he can review the issue if he's interested.

> RuntimeError: dictionary changed size during iteration

I didn't see this bug the last 5 years, so I consider that the issue has been fixed in the meanwhile :-)