Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#777 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
backend, networking

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Cython
Star
11.9k
Fork
615
Merge trung bình
4 giờ 43 phút
Pull request đã merge (30 ngày)
3

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của MagicStack/uvloop

Tất cả issue của MagicStack/uvloop

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.