Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Collecting a context together with its memory segfaults

Cerrado
  • ¿Algo no está bien?
#714 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #716 de @maleadt — fusionado

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
julia
Área
backend

Línea de trabajo

Start with the ZeContext finalizer and the memory allocation and release paths in oneAPI.jl; the issue does not name their files or tests. Trace how context ownership interacts with allocations that become unreachable in the same collection, then check the proposed lifecycle against the CUDA.jl comparison and Level Zero constraints. Done means collecting a context and its allocations no longer segfaults; an open pull request already addresses this issue.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

runtime

Every Level Zero object is destroyed by its own finalizer, and Julia runs the finalizers of objects that become unreachable in the same collection in no particular order. A ZeContext can thus be destroyed before memory allocated in it, and freeing that memory afterwards crashes in NEO:

using oneAPI, oneAPI.oneL0

function work()
    ctx = ZeContext(oneAPI.driver())
    for _ in 1:3; GC.gc(true); end   # the context is old by the time the array is allocated
    old = context()
    context!(ctx)
    a = oneArray{Float32}(undef, 1_000_000)
    context!(old)
    return
end
work()
GC.gc(true)

[19895] signal 11 (1): Segmentation fault
_ZN2L07Context7freeMemEPKvb at libze_intel_gpu.so.1
zeMemFree at ...

This fails every time on an Iris Xe with NEO 26.35. Without the collections before the allocation the finalizers happen to run in a working order. A context in which a kernel was launched, or small (pooled) arrays were allocated, stays reachable from oneAPI.jl's caches and is never collected, which is probably why this hasn't come up.

Forcing other parent-before-child orders (a queue before its fences, an event pool before its events, a module before its kernels, a command list while it is executing) does not crash on NEO, though the Level Zero spec doesn't allow them either. The context is the one that matters: destroying it frees the allocations made in it.

CUDA.jl avoids this by not destroying contexts from a finalizer at all (CuContext has no finalizer, see also JuliaGPU/CUDA.jl#3404 for releases after an explicit destroy).

Lenguaje dominante
Julia
Estrellas
218
Forks
36
Merge medio
1 d 4 h
PR fusionados (30 d)
55

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

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de JuliaGPU/oneAPI.jl

Todos los issues de JuliaGPU/oneAPI.jl

Issues similares

Más issues de Julia

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.