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

Loop.close() can hang indefinitely on an in-flight libuv getaddrinfo request

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, networking

Línea de trabajo

Start by reading uvloop/loop.pyx around Loop._close() and trace the final UV_RUN_DEFAULT drain against outstanding uv_getaddrinfo requests. Run the provided deterministic reproducer on Linux with uvloop 0.22.1, then check behavior on 0.23.0. Done means Loop.close() does not wait indefinitely for blocked native DNS work while preserving request and callback lifetime safety; the issue does not name a regression test file.

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

Descripción

Summary

uvloop.Loop.close() can block indefinitely when an in-flight libuv uv_getaddrinfo request is still running in a worker thread. The final synchronous uv_run(UV_RUN_DEFAULT) in Loop._close() waits for outstanding requests, even after all open handles have been closed. If native DNS resolution stalls, close() stalls with it.

I reproduced this deterministically on uvloop 0.22.1 / CPython 3.13.5 / Linux x86_64 using an LD_PRELOAD shim to delay getaddrinfo() (no broken DNS or network access required). Under the same conditions, standard-library asyncio's loop.close() returns immediately.

Version caveat: I have not executed the reproducer against the 0.23.0 binary. However, the relevant shutdown code remains in the v0.23.0 tag, which upgrades vendored libuv to 1.52.1. The findings below are runtime results for 0.22.1, not a claimed runtime confirmation for 0.23.0.

Environment verified

  • OS: Linux x86_64 (kernel 6.18.44 in the reproduced run)
  • Python: CPython 3.13.5
  • uvloop: 0.22.1
  • Comparison: stdlib asyncio on the same Python installation
  • Build prerequisite for deterministic test: C compiler (cc)

Minimal deterministic reproducer

Reproducer files (gist):

  • reproduce_uvloop_close_hang.py: self-contained runner; compiles its own C interception shim, runs uvloop and asyncio in isolated child processes, and enforces a watchdog timeout.
  • uvloop_close_minimal.py and uvloop_close_block_dns.c: smaller two-file version, Linux only.
  • observed_results.txt: full captured output of the verified runs.

On Linux:

python -m pip install 'uvloop==0.22.1'
python reproduce_uvloop_close_hang.py --block-seconds 10 --timeout 3

To check the latest reported release (not yet validated by me):

python -m pip install 'uvloop==0.23.0'
python reproduce_uvloop_close_hang.py --block-seconds 10 --timeout 3

The runner prints the version actually installed. It injects a 10-second delay in native getaddrinfo() for block-uvloop-test.invalid, schedules loop.getaddrinfo() without awaiting completion, and calls loop.close() after the worker has started. The watchdog applies to close() as observed from the parent process. It uses os._exit(0) only after close() returns to prevent Python interpreter shutdown from independently waiting for a still-running executor thread in the asyncio control case.

Observed result (uvloop 0.22.1)

10-second native DNS delay; 3-second watchdog:

--- uvloop ---
IMPL: uvloop 0.22.1
SHIM_STARTED: native getaddrinfo; sleeping 10s
PRE_CLOSE: task_done=False
CLOSE_ENTER
RESULT: WATCHDOG_TIMEOUT
CONFIRMED: close() did not return while DNS was blocked

--- asyncio ---
IMPL: stdlib asyncio
SHIM_STARTED: native getaddrinfo; sleeping 10s
PRE_CLOSE: task_done=False
CLOSE_ENTER
CLOSE_RETURN after 0.000s
RESULT: EXIT_0
CONTROL: stdlib asyncio close() returned

2-second native DNS delay; 6-second watchdog:

  • uvloop's close() returned after 1.700 seconds inside close() (the DNS work had already been running for about 0.3 seconds).
  • During DNS completion, uvloop logged an unhandled RuntimeError: Event loop is closed from __on_addrinfo_resolved / _getaddrinfo.callback attempting to schedule a callback.
  • The stdlib asyncio control still returned immediately.

No transport or socket leak is required to reproduce the stall.

Likely cause

In uvloop/loop.pyx on the v0.23.0 tag, Loop._close() ends its handle cleanup with:

__close_all_handles(self)
self._shutdown_signals()
# During this run there should be no open handles,
# so it should finish right away
self.__run(uv.UV_RUN_DEFAULT)

The assumption does not account for active requests. uv_getaddrinfo uses a uv_getaddrinfo_t request, which is not a handle visited by uv_walk(). libuv documents that UV_RUN_DEFAULT runs until no active referenced handles or requests remain. Its request API also documents that uv_cancel() cannot cancel an already executing request and that callback ownership/lifetime constraints persist after cancellation.

As a result, if the underlying resolver never returns, a synchronous Loop.close() can remain stuck in that final drain indefinitely.

Expected behavior

Calling loop.close() should not block indefinitely on invisible, uninterruptible native DNS/threadpool work. This differs from the stdlib asyncio close contract, which explicitly does not wait for executor work to finish. A fix should preserve libuv request and callback lifetime safety; simply stopping the drain without cleaning up native requests may not be safe.

Related background

  • CPython #78218: discussion of not waiting for background executor work during close().
  • uvloop #335: shutdown hang after KeyboardInterrupt, but no established uv_getaddrinfo mechanism.
  • uvloop #414: intermittent hangs/FD errors, addressed by an unrelated double-close fix.

I did not find an existing issue or PR documenting this specific Loop._close() → UV_RUN_DEFAULT → active uv_getaddrinfo stall. The attached deterministic reproducer could also be adapted into a regression test.

Lenguaje dominante
Cython
Estrellas
11.9k
Forks
615
Merge medio
4 h 43 min
PR fusionados (30 d)
3

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 MagicStack/uvloop

Todos los issues de MagicStack/uvloop

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.