Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#777 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
backend, networking

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Cython
Sterne
11.9k
Forks
615
Ø Merge
4 Std. 43 Min.
Gemergte PRs (30 T.)
3

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus MagicStack/uvloop

Alle Issues in MagicStack/uvloop

Ähnliche Issues

Weitere Issues zu Backend & API Design

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.