Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#777 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python
Domaine
backend, networking

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Cython
Étoiles
11.9k
Forks
615
Merge moyen
4 h 43 min
PR mergées (30 j)
3

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de MagicStack/uvloop

Toutes les issues de MagicStack/uvloop

Issues similaires

Plus d'issues Backend & API Design

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.