SharedMemory constructor raises "cannot mmap an empty file" exception
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- operating-systems
Línea de trabajo
Comienza en Lib/multiprocessing/shared_memory.py, en el constructor de SharedMemory, y revisa la ruta de excepciones alrededor de mmap.mmap. Ejecuta la reproducción mostrada en la issue en la plataforma afectada y, después, inspecciona el PR vinculado gh-133227. Se considera completado cuando un objeto de memoria compartida de tamaño cero puede limpiarse mediante la ruta de la biblioteca estándar sin dejar ValueError sin gestionar.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Bug report
I was trying to clean up a shared memory object left behind by an earlier process using the following code:
shm = SharedMemory("some_name")
shm.close()
shm.unlink()
However, the first line resulted in an exception being raised:
File "/home/USER/.pyenv/versions/3.9.10/lib/python3.9/multiprocessing/shared_memory.py", line 114, in __init__
self._mmap = mmap.mmap(self._fd, size)
ValueError: cannot mmap an empty file
The exception handler around that line unlinks the object in case of an OSError, but not in case of this ValueError raised by mmap.mmap:
This makes it effectively impossible to clean up this particular shared memory object through the standard library.
I'm not sure how the shared memory object was corrupted in the first place, but it looks like the exception is triggered because os.fstat states that it has size 0:
>>> f = _posixshmem.shm_open('some_name', os.O_RDWR, mode=0o600)
>>> os.fstat(f)
os.stat_result(st_mode=33152, st_ino=80, st_dev=27, st_nlink=1, st_uid=1000, st_gid=1000, st_size=0, st_atime=1651836036, st_mtime=1651836036, st_ctime=1651836036)
After which the code tries to mmap with size 0 and fails with the exception mentioned earlier.
I was only able to resolve this by calling _posixshmem.shm_unlink('some_name') manually. I think the exception handler should be extended to also unlink the file if it was truncated to 0 like this.
This scenario can be reproduced with the following code:
import _posixshmem
import os
from multiprocessing.shared_memory import SharedMemory
f = _posixshmem.shm_open('test', os.O_RDWR | os.O_CREAT | os.O_EXCL, 0o600)
os.close(f)
try:
mem = SharedMemory("test")
finally:
_posixshmem.shm_unlink("test")
Your environment
- CPython versions tested on: 3.9.10
- Operating system and architecture: Ubuntu 20.04.3 LTS
Linked PRs
- gh-133227
- Lenguaje dominante
- Python
- Estrellas
- 77.2k
- Forks
- 36k
- Merge medio
- 1 d 9 h
- PR fusionados (30 d)
- 558
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de python/cpython
-
docs pending
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
stdlib type-feature
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
stdlib type-feature
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
build type-bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
stdlib topic-email type-feature
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Todos los issues de python/cpython
Issues similares
-
fix: inaccuracy ⚠️
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
uabrc/uabrc.github.io#1255 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
ethereum-optimism/factory#64 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
duckdb/duckdb-python#627 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Add link for tutorial Abiertodocumentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
Qiskit/qiskit-addon-sqd#376 ·