Bug report
multiprocessing.resource_tracker fails to track files with a colon (':') in the filename due to a parsing error, allowing resource leaks. I originally encountered this while working with filenames that include ISO8601 timestamps with colons as time separators.
Minimal example:
$ python -c "from multiprocessing.shared_memory import SharedMemory; shm = SharedMemory(create=True, size=1, name='a:b')" $ Traceback (most recent call last): File "/usr/lib/python3.10/multiprocessing/resource_tracker.py", line 199, in main cmd, name, rtype = line.strip().decode('ascii').split(':') ValueError: too many values to unpack (expected 3) $ ls /dev/shm/a\:b /dev/shm/a:b
Without the colon, the file is correctly tracked and removed:
$ python -c "from multiprocessing.shared_memory import SharedMemory; shm = SharedMemory(create=True, size=1, name='ab')" $ /usr/lib/python3.10/multiprocessing/resource_tracker.py:224: UserWarning: resource_tracker: There appear to be 1 leaked shared_memory objects to clean up at shutdown warnings.warn('resource_tracker: There appear to be %d ' $ ls /dev/shm/ab ls: cannot access '/dev/shm/ab': No such file or directory
Your environment
- CPython versions tested on: 3.10.7, 3.11.0, 3.12.0a1
- Operating system and architecture: Fedora 35 x86_64 (3.10.7 from Fedora, others with Docker images)
Linked PRs
- gh-98896: Fix parsing issue in resource_tracker to allow shared memory names containing colons #138473
- [3.14] gh-98896: resource_tracker: use json&base64 to allow arbitrary shared memory names (GH-138473) #141922
- [3.13] gh-98896: resource_tracker: use json&base64 to allow arbitrary shared memory names (GH-138473) #142014