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.

Author knl
Recipients Andrei Pozolotin, asvetlov, knl, yselivanov
Date 2021-06-29.14:48:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1624978116.64.0.947048238377.issue43832@roundup.psfhosted.org>
In-reply-to
Content
Oh, it looks like it's because the context for the Event doesn't match when created this way (the default context on linux is fork). 

The problem goes away if the Event instance is created from the spawn context -- specifically, patching dump_core.py 

```
@@ -22,14 +22,13 @@ def master_func(space:dict) -> None:

 if __name__ == "__main__":

-    this_event = multiprocessing.Event()
+    context_spawn = multiprocessing.get_context("spawn")

+    this_event = context_spawn.Event()
     this_space = dict(
         this_event=this_event,
     )

-    context_spawn = multiprocessing.get_context("spawn")
-
     master_proc = context_spawn.Process(
```

I think this can be closed; the incompatibility between contexts is also documented at https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Lock, thought it could be a little more explicit about potential segfaults.

> Note that objects related to one context may not be compatible with processes for a different context. In pait's berticular, locks created using the fork context cannot be passed to processes started using the spawn or forkserver start methods.

(Event uses a Lock under the hood)
History
Date User Action Args
2021-06-29 14:48:36knlsetrecipients: + knl, asvetlov, yselivanov, Andrei Pozolotin
2021-06-29 14:48:36knlsetmessageid: <1624978116.64.0.947048238377.issue43832@roundup.psfhosted.org>
2021-06-29 14:48:36knllinkissue43832 messages
2021-06-29 14:48:36knlcreate