multiprocessing.shared_memory: failed attach unlinks another process's block
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- PR マージ指標
- PR 指標を取得中
説明
Bug report
Bug description
SharedMemory.__init__ calls self.unlink() from its OSError cleanup handler:
try:
if create and size:
os.ftruncate(self._fd, size)
stats = os.fstat(self._fd)
size = stats.st_size
self._mmap = mmap.mmap(self._fd, size)
except OSError:
self.unlink()
raise
This runs unconditionally, including on the attach path (create=False).
unlink() calls shm_unlink(), which permanently destroys the named block.
So if mmap() fails while attaching to a block created by another process
(e.g. ENOMEM under memory pressure), the failing attach destroys another
owner's live shared memory block.
Reproduction (simulating an mmap failure during attach):
from unittest import mock
from multiprocessing import shared_memory
owner = shared_memory.SharedMemory(create=True, size=1024)
try:
with mock.patch("multiprocessing.shared_memory.mmap.mmap",
side_effect=OSError("ENOMEM")):
shared_memory.SharedMemory(owner.name) # attach
except OSError:
pass
shared_memory.SharedMemory(owner.name) # FileNotFoundError: block destroyed
Secondary issue: resource_tracker.register() runs after this try/except, so
on the create=True path the block is not yet registered. unlink() still
calls resource_tracker.unregister(), so the resource_tracker does
cache[rtype].remove(name) on an unknown name → KeyError printed as a
traceback, with the tracker's exit code set to 3.
Expected behavior
A failed attach must not unlink a block it does not own. On error the fd should
just be closed; the block should be unlinked only when it was created in this
call, and without a spurious unregister for a never-registered block.
Your environment
- CPython main (3.16.0a0); also affects earlier versions
- Linux / POSIX shared memory (
_USE_POSIX)
Linked PRs
- gh-153280
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
multiprocessing.shared_memory.SharedMemory.init から始め、issue に示されている mock を使って attach の失敗を再現します。attach パスと create パスの両方について、cleanup と resource-tracker の動作を確認します。完了の条件は、attach に失敗しても既存のブロックが使用可能なままで、tracker の見せかけのエラーが発生しないことです。issue にはリンクされた PR gh-153280 が含まれています。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- operating-systems
- issue の種類
- バグ
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 25/100