Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#777 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
backend, networking

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Cython
Estrelas
11.9k
Forks
615
Merge médio
4h 43min
PRs com merge (30d)
3

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de MagicStack/uvloop

Todas as issues de MagicStack/uvloop

Issues semelhantes

Mais issues de Backend & API Design

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.