Repository navigation
Issues when combined with multiprocessing (MaybeEncodingError, BadZipFile, OSError) #520
Description
Activity
Looking at this in detail I learned:
- The issue stems from More speedup via mtime-base caching. #274 (since v3.8.0) as can be seen since simply removing the
@functools.lru_cache()annotation fixes it, so potentially @anntzer has an idea of how to properly fix this? - The issue only occurs when one has
.eggfiles insys.pathsince in that casezipp.Path(zipfile.Path) objects are kept in memory indefinitely. A more detailed explanation of why this issue occurs can be found below. - The issue only occurs when one uses multiprocessing
forkas spawn method (can be enforced withmultiprocessing.set_start_method('spawn')) - A workaround (which should not be the final solution) is using
multiprocessing.set_start_method('fork')instead - put everything that should not be executed in each subprocess (including theset_start_method) in aif __name__ == "__main__":block for that to work
More context: Due to the caching introduced in #274, references to
FastPathobjects are stored indefinitely. If one has.eggfiles in ones Python paths, theFastPathobjects hold azipfile.Path(actuallyzipp.Path) object created inFastPath.zip_children. As long as that object exists, it keeps a file handler to that zip file open. And that open file handler is a problem when used withmultiprocessingand especially themultiprocessingspawn methodfork(default in my case, can be enforced withmultiprocessing.set_start_method('spawn')), compare also python/cpython#83544 .The open file handlers can also be observed by adding
import psutil proc = psutil.Process() print(proc.open_files())after the line
eps = [dist.entry_points for dist in dists]in the example above.- The issue stems from More speedup via mtime-base caching. #274 (since v3.8.0) as can be seen since simply removing the
I didn't look much in depth into the issue, but a way to fix this kind of cache+multiprocessing incompatibility is to clear the cache when starting the child process via https://docs.python.org/3/library/os.html#os.register_at_fork, see e.g. https://github.com/matplotlib/matplotlib/blob/3574a7e8f5243f93c6442e43b4c583448fc95dc6/lib/matplotlib/font_manager.py#L1584-L1590
Reacted by 2xB- added a commit that references this issue
on Jun 8, 2025 Thank you very much! I did not consider the existence of
os.register_at_fork, that is a very simple fix. In the meantime, that also means a very simple workaround is to useimport os, importlib_metadata os.register_at_fork(after_in_child=importlib_metadata.FastPath.__new__.cache_clear)
before the
multiprocessingcalls.@jaraco What is the status here? If there is anything I can do to improve this, please tell!
Oh, I of course meant the status of the fixing pull request #521, not the status of this issue.
Sorry for the delay in review. I'm still catching up on issues from May, but the PR caught my eye.
The
register_at_forkseems like a suitable workaround. I worry it's not quite the proper fix (it feels a little bit like the problem lies in zipfile or zipp, as mentioned above). I do like that the proposed solution is essentially only activated at the appropriate scope (multiprocessing + fork).I'll review the PR and get something merged.
I vaguely recall there may be some work to eliminate FastPath (maybe in CPython), so that may also be relevant, but I don't recall where off the top of my head. Regardless, we can merge this here and reconcile any conflicts when applying upstream.
- added 2 commits that reference this issue
on Dec 21, 2025
In use with multiprocessing (e.g. when pickling
awkwardarrays to transmit them from a subprocess to the host), I see issues withimportlib_metadata. This was originally observed by @richeldichel asmultiprocessing.pool.MaybeEncodingError: Error sending result:with then appendedBadZipFileerror orOSError. I could get this down to the following minimal working example that sometimes (every second to every tenths try) reproduces the underlying error:(edit: this is a more simplified version:)
Tested with Python 3.10.12 with
importlib-metadata==8.7.0and Python 3.8.10 withimportlib-metadata==8.5.0. It has to be noted that in the latter test environment, the issue only occurs for me when doingexport PYTHONPATH=/home/.../.local/lib/python3.8/site-packages/beforehand.Below is an exemplary error log:
I also saw
zipfile.BadZipFile: Overlapped entries: 'EGG-INFO/PKG-INFO' (possible zip bomb)and