SharedMemory: resource_tracker gets confused by leading slashes on Linux #105380
Description
Bug report
Shared memory names act as "file paths" on Linux, therefore no matter how many / characters they start with, they count as only one to the system. But resource_tracker doesn't account for this.
See this repro involving two interpreters running at the same time:
| Process 1 | Process 2 | /dev/shm/abc exists |
|---|---|---|
from multiprocessing.shared_memory import SharedMemory |
from multiprocessing.shared_memory import SharedMemory |
no |
shm = SharedMemory("abc", True, 10) |
yes | |
shm = SharedMemory("/abc", False) |
yes | |
shm.buf[0] = 42 |
yes | |
assert(shm.buf[0] == 42) |
yes | |
shm.unlink() |
no | |
assert(shm.buf[0] == 42) |
assert(shm.buf[0] == 42) |
no |
exit() |
no | |
shm.unlink() # raises exception |
no | |
exit() # prints warning |
no |
At this point, calling shm.unlink() in Process 2 throws an exception, which may be unexpected.
And regardless if it is called or not, Process 2 prints UserWarning: resource_tracker: There appear to be 1 leaked shared_memory objects to clean up at shutdown at exit, even though nothing got leaked.
Note that /abc could also have been //abc, ///abc, and so on. On macOS and Windows however, all of these names belong to distinct objects.
Your environment
- CPython versions tested on: 3.11.3
- Operating system and architecture: Fedora Linux 38, x86_64