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.

Title: multiprocessing cx_Freeze windows GUI bug (& easy fixes)
Type: behavior Stage: resolved
Components: Windows Versions: Python 3.3
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: akamos, davin, mark, sbt
Priority: normal Keywords: patch

Created on 2014-02-12 13:00 by mark, last changed 2022-04-11 14:57 by admin. This issue is now closed.

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 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) * (Python committer) 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) * (Python committer) 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.
Date User Action Args
2022-04-11 14:57:58adminsetgithub: 64806
2016-04-14 11:32:42akamossetnosy: + akamos
messages: + msg263397
2015-12-28 08:45:09marksetmessages: + msg257109
2015-12-27 16:57:05davinsetstatus: open -> closed
resolution: out of date
messages: + msg257081

stage: resolved
2015-11-06 06:51:55marksetmessages: + msg254169
2015-11-06 03:17:54davinsettype: behavior

messages: + msg254166
nosy: + davin
2015-10-28 10:05:17marksetmessages: + msg253595
2014-02-12 20:25:28ned.deilysetnosy: + sbt
2014-02-12 16:19:45marksetmessages: + msg211098
2014-02-12 13:00:07markcreate