➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2014-02-12 13:00 by mark, last changed 2022-04-11 14:57 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| multiprocessing.diff | mark, 2014-02-12 13:00 | diff of multiprocessing/{forking,managers,process}.py | ||
| Messages (8) | |||
|---|---|---|---|
| msg211089 - (view) | Author: Mark Summerfield (mark) * | Date: 2014-02-12 13:00 | |
I have a Python Windows GUI application (using PySide) that uses multiprocessing. When I freeze the application I get error messages, in particular that mulitprocessing cannot call flush on a null object. ISTM That in a Windows GUI application, sys.stdout and sys.stderr may well be None since there is no attached console. So, I added guards to accesses to sys.stdout and sys.stderr and the problems went away. I'm not used to creating patch diffs but hopefully the attached (with just a few lines of changes) will be easy to understand. |
|||
| msg211098 - (view) | Author: Mark Summerfield (mark) * | Date: 2014-02-12 16:19 | |
My change to managers.py is redundant; sorry about that. |
|||
| msg253595 - (view) | Author: Mark Summerfield (mark) * | Date: 2015-10-28 10:05 | |
I've now signed the contributor agreement.
However, with Python 3.4 I don't seem to get the same problem anymore even though there are a few places in the code where sys.std{err,out} are used without if ... is not None guards.
|
|||
| msg254166 - (view) | Author: Davin Potts (davin) *  |
Date: 2015-11-06 03:17 | |
Mark: Patches to 3.3 are generally not being considered (due to its age) but patches to 3.5 (possibly 3.4) would be. You suggest the issue can't be reproduced in 3.4 but have to tried in the current 3.5 release? |
|||
| msg254169 - (view) | Author: Mark Summerfield (mark) * | Date: 2015-11-06 06:51 | |
No, I'm sorry I haven't tried with 3.5; in fact, there doesn't seem to be a cx_Freeze available for 3.5 yet. |
|||
| msg257081 - (view) | Author: Davin Potts (davin) * |
Date: 2015-12-27 16:57 | |
Given that the issue can not be reproduced except on an older version (3.3) that is no longer being actively maintained, the proper thing to do is mark this as "out of date". If the problem recurs with 3.5 (once cx_Freeze can be tried there) then a new bug should be opened at that time. Mark: I recommend moving to a newer version, specifically 3.4 would seem like a winner for you. If you are truly stuck for whatever reason on 3.3 and your patch works for you, I'd suggest using it there until you can migrate to a more recent release. |
|||
| msg257109 - (view) | Author: Mark Summerfield (mark) * | Date: 2015-12-28 08:45 | |
Thanks Davin. I have indeed moved to 3.4 which does not seem to have the bug. (I can't move to 3.5 because I can't install 32- and 64-bit versions as I can with 3.4 due to the new installers -- or rather I can, but this confuses the pywin32 and apsw installers both of which I need.) |
|||
| msg263397 - (view) | Author: akamos (akamos) | Date: 2016-04-14 11:32 | |
I have also trouble with this bug. It wasn't fixed in Python 3.4 and Python 3.5. It should be reopened. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:57:58 | admin | set | github: 64806 |
| 2016-04-14 11:32:42 | akamos | set | nosy:
+ akamos messages: + msg263397 |
| 2015-12-28 08:45:09 | mark | set | messages: + msg257109 |
| 2015-12-27 16:57:05 | davin | set | status: open -> closed resolution: out of date messages: + msg257081 stage: resolved |
| 2015-11-06 06:51:55 | mark | set | messages: + msg254169 |
| 2015-11-06 03:17:54 | davin | set | type: behavior messages: + msg254166 nosy: + davin |
| 2015-10-28 10:05:17 | mark | set | messages: + msg253595 |
| 2014-02-12 20:25:28 | ned.deily | set | nosy:
+ sbt |
| 2014-02-12 16:19:45 | mark | set | messages: + msg211098 |
| 2014-02-12 13:00:07 | mark | create | |