There may be a bug in how tkinter frames are handled when called in multiple processes in OS X.

I am trying to run a simple script that defines a new Frame subclass and then attempts to call it multiple times in separate processes using the multiprocessing module. When the frame's mainloops are called the process crashes. I've included the script where this problem is occurring.

The crash report specifies python, and among a bunch of boilerplate information includes the following lines:

Application Specific Information:
*** multi-threaded process forked ***
crashed on child side of fork pre-exec

This is happening in Python 3.4.3, running in OS X 10.10.4. In testing this on alternative platforms (Windows and Linux) it appears to work, suggesting it may be a bug in OS X's implementation.

Your test code works for me on linux and python3.3 and 3.4.1.  That is, I can click four buttons and get back the prompt, with no segfault.  It is quite possible this is a bug in the Mac version of TK, assuming this is even supposed to work.

A web search will find multiple hits for problems with using Tk (and Tkinter) with multiprocess on OS X and elsewhere.  On OS X, there is a well-known and documented restriction that impacts Tk-based apps:

"When launching separate processes using the fork function, you must always follow a call to fork with a call to exec or a similar function. Applications that depend on the Core Foundation, Cocoa, or Core Data frameworks (either explicitly or implicitly) must make a subsequent call to an exec function or those frameworks may behave improperly."

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/AboutThreads/AboutThreads.html

For a specific example of problems using tkinter and multiprocessing see:
http://stackoverflow.com/questions/23599087/multiprocessing-python-core-foundation-error

Some suggest that you *might* be able to get things to work as long as you defer importing tkinter (and, thus, initializing Tcl and Tk) until after all of the processes are created.  But, in general, it's not a good idea to separate tkinter calls across multiple processes.  See Bryan Oakley's advice in the above SO link:

"You'll need to keep all GUI code in the master process, and have your other process communicate with it via a queue."

This is likely a known issue with using os.fork on OSX: that is unsafe, and likely causes crashes, once one of Apple's frameworks has initialized. 

I think it might be better in the long run to make multiprocessing on OSX behave the same as on windows, but haven't thought about the consequences of this enough to be sure (because there are downsides as well)

BTW. Besides that, the code pattern doesn't match how GUI applications are supposed to work on OSX. Applications are basically supposed to be single process, even when working with multiple documents. 

--
On the road, hence brief. 

Op 6 jul. 2015 om 15:57 heeft R. David Murray <report@bugs.python.org> het volgende geschreven:

> 
> R. David Murray added the comment:
> 
> Your test code works for me on linux and python3.3 and 3.4.1.  That is, I can click four buttons and get back the prompt, with no segfault.  It is quite possible this is a bug in the Mac version of TK, assuming this is even supposed to work.
> 
> ----------
> nosy: +r.david.murray
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue24573>
> _______________________________________

Yeah it is a bug in OS X, fixed by setting the python multiprocessing start method to 'forkserver' instead of the default fork.

This is another instance of the following bug: http://bugs.python.org/issue27126

libdispatch (grand central dispatch) is not fork safe. The forkserver approach is a good workaround, thanks!