resize! frees its new buffer with free instead of release
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 78/100
Línea de trabajo
Lee el finalizador de resize! en src/array.jl:659-661 y compáralo con el finalizador del constructor de arrays en src/array.jl:129-131 y con release en src/pool.jl. Revisa las pruebas pertinentes del finalizador o de gestión de memoria y ejecútalas; el trabajo estará terminado cuando los búferes redimensionados se liberen mediante release(buf), de modo que se aplique su comportamiento de contabilidad y sincronización.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The buffer that resize! allocates is freed by a finalizer that calls free(buf) (src/array.jl:659-661 at 0c02df0), whereas the array constructor's finalizer calls release(buf) (src/array.jl:129-131). That skips everything release does (src/pool.jl):
_allocated_bytesis never decremented for resized device and shared buffers, so the proactive-GC thresholds see memory that was freed long ago as still allocated;- on the LTS stack, the queues that may still reference the buffer aren't synchronized before freeing, which is the workaround for NEO 25.18 unmapping memory with work in flight (a GPU page fault that bans the context);
- the free doesn't use
ZE_DRIVER_MEMORY_FREE_POLICY_EXT_FLAG_BLOCKING_FREE.
So a vector that was resize!d and then becomes garbage while its last kernel is still running can take down the context on LTS. Using release(buf) in that finalizer, like the constructor does, should fix all three.
- Lenguaje dominante
- Julia
- Estrellas
- 217
- Forks
- 37
- Merge medio
- 18 h 12 min
- PR fusionados (30 d)
- 26
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 JuliaGPU/oneAPI.jl
-
Wrong results for overflowing Int16 arithmetic in a reduction kernelPosiblemente ocupada @maleadt la tomó hoy. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
JuliaGPU/oneAPI.jl#663 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
JuliaGPU/oneAPI.jl#607 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de JuliaGPU/oneAPI.jl
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
oxfordcontrol/COSMO.jl#211 ·
-
documentation
Dificultad 2/5 Medio día Aptitud para principiantes 65/100
Los mantenedores suelen responder en 6 días
-
Out-of-place JLArray/GPU problem with VectorContinuousCallback scalar-indexes (callback cache built with CPU zeros)Posiblemente ocupada @ChrisRackauckas-Claude la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
SciML/OrdinaryDiffEq.jl#4813 ·
Los mantenedores suelen responder en 1 día
-
ARKODE: callbacks that modify `u` throw MethodError on reinitPosiblemente ocupada @devmotion la tomó hace 1 día. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
SciML/Sundials.jl#575 ·
-
broken links in docsAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día