[issue8333] test_multiprocessing: pickling failures

Michael Foord added the comment: Green build on Windows XP, trunk. http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%20trunk/builds/282 -- resolution: -> accepted stage: needs patch -> committed/rejected status: open -> closed ___ Python t

[issue8333] test_multiprocessing: pickling failures

Michael Foord added the comment: I believe this issue to now be fixed on trunk. We can close this when the buildbots are passing again. -- ___ Python tracker ___ ___

[issue8333] test_multiprocessing: pickling failures

Michael Foord added the comment: Changing unittest.TestResult to use StringIO instead of cStringIO isn't sufficient. regrtest.py also needs to use StringIO... -- ___ Python tracker

[issue8333] test_multiprocessing: pickling failures

Michael Foord added the comment: Although merely switching to StringIO may not be enough. TestResult objects keep a reference to sys.stdout when they are instantiated and you can't pickle that either. It is preferable for the reference to be taken at instantiation time rather than stored as

[issue8333] test_multiprocessing: pickling failures

Michael Foord added the comment: TestResult creates its StringIO buffers even if they aren't use. I can create them on first use and use StringIO.StringIO rather than cStringIO. Will fix now. -- ___ Python tracker

[issue8333] test_multiprocessing: pickling failures

Changes by Martin v. Löwis : -- priority: high -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8333] test_multiprocessing: pickling failures

Martin v. Löwis added the comment: BTW, this is also causing all Windows buildbots to fail. -- keywords: +buildbot ___ Python tracker ___

[issue8333] test_multiprocessing: pickling failures

Martin v. Löwis added the comment: Perhaps we could run the multiprocessing tests unbuffered? -- nosy: +loewis ___ Python tracker ___

[issue8333] test_multiprocessing: pickling failures

Michael Foord added the comment: I expect the unittest tests will fail with that patch applied however... No problem with switching to just using StringIO in unittest though - preferably with a comment as to why. -- ___ Python tracker

[issue8333] test_multiprocessing: pickling failures

Changes by Stefan Krah : -- keywords: +patch Added file: http://bugs.python.org/file16805/issue8333.patch ___ Python tracker ___ ___ Py

[issue8333] test_multiprocessing: pickling failures

Stefan Krah added the comment: It was introduced in r79623, and the attached patch makes the problem go away. I would be happy to apply it, but I perhaps you and Michael could analyze if there are unwanted dependencies between multiprocessing and unittest. -- nosy: +michael.foord _

[issue8333] test_multiprocessing: pickling failures

Jesse Noller added the comment: When did this problem start? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8333] test_multiprocessing: pickling failures

Changes by R. David Murray : -- nosy: +jnoller ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue8333] test_multiprocessing: pickling failures

Tim Golden added the comment: Seeing the same thing on 32-bit WinXP on x86 On 07/04/2010 14:34, Stefan Krah wrote: > > New submission from Stefan Krah: > > On Windows/amd64, I get loads of pickling errors in test_multiprocessing. > > Type 1 error: > > Traceback (most recent call last): >Fil

[issue8333] test_multiprocessing: pickling failures

New submission from Stefan Krah : On Windows/amd64, I get loads of pickling errors in test_multiprocessing. Type 1 error: Traceback (most recent call last): File "", line 1, in File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 347, in main self = load(from_parent)