[New-bugs-announce] [issue40882] memory leak in multiprocessing.shared_memory.SharedMemory in Windows

Eryk Sun report at bugs.python.org
Fri Jun 5 18:47:05 EDT 2020

New submission from Eryk Sun <eryksun at gmail.com>:

mmap.mmap in Windows doesn't support an exist_ok parameter and doesn't correctly handle the combination fileno=-1, length=0, and tagname with an existing file mapping. SharedMemory has to work around these limitations. 

Part of the workaround for the create=False case requires mapping a view via MapViewOfFile in order to get the size from VirtualQuerySize, since mmap.mmap requires it (needlessly if implemented right) when fileno=-1. This mapped view never gets unmapped, which means the shared memory will never be freed until the termination of all processes that have opened it with create=False. Also, at least in a 32-bit process, this wastes precious address space.

_winapi.UnmapViewOfFile needs to be implemented. Then the temporary view can be unmapped as follows:

    self._name = name
    h_map = _winapi.OpenFileMapping(_winapi.FILE_MAP_READ, False, name)
        p_buf = _winapi.MapViewOfFile(h_map, _winapi.FILE_MAP_READ, 0, 0, 0)
        size = _winapi.VirtualQuerySize(p_buf)
    self._mmap = mmap.mmap(-1, size, tagname=name)

[1]: https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-unmapviewoffile

components: Library (Lib), Windows
messages: 370794
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: memory leak in multiprocessing.shared_memory.SharedMemory in Windows
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

Python tracker <report at bugs.python.org>

More information about the New-bugs-announce mailing list