http.client.HTTPConnection.connect() leaks the socket when setting TCP_NODELAY fails (EINVAL on macOS after a reset)
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- PR マージ指標
- PR 指標を取得中
説明
Bug report
Bug description:
http.client.HTTPConnection.connect() creates the socket, then sets TCP_NODELAY on it:
self.sock = self._create_connection(
(self.host,self.port), self.timeout, self.source_address)
# Might fail in OSs that don't implement TCP_NODELAY
try:
self.sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
except OSError as e:
if e.errno != errno.ENOPROTOOPT:
raise
If setsockopt() fails with anything other than ENOPROTOOPT, the error propagates with self.sock still holding the open, connected socket. A caller that drops the connection object then leaks the socket:
ResourceWarning: unclosed <socket.socket fd=4, family=2, type=1, proto=6, laddr=('127.0.0.1', 62584), raddr=('127.0.0.1', 62583)>
This is not hypothetical. On macOS, setsockopt(TCP_NODELAY) raises EINVAL once the peer has reset the connection. Racing a server that accepts and immediately closes with SO_LINGER set to zero (an RST) against a client that connects and sets TCP_NODELAY, 299 of 400 attempts on macOS 26 raised OSError(22, 'Invalid argument') from setsockopt(), one raised ECONNRESET, and 100 succeeded.
That is exactly the scenario of test_ssl.TestPreHandshakeClose.test_https_client_non_tls_response_ignored, whose server responds and resets the connection right after accepting. When the reset wins the race, connect() raises from setsockopt() instead of from the TLS handshake the test expects, and the plain socket is never closed. The test still passes (it only requires an OSError), but the socket is finalized after the test method returns, and regrtest reports the module as "env changed". Seen on the macOS x86-64 CI job of 374851f3db, in both the initial run and the rerun: https://github.com/python/cpython/actions/runs/33514119791/job/99876792339
test_https_client_non_tls_response_ignored (test.test_ssl.TestPreHandshakeClose.test_https_client_non_tls_response_ignored) ... Warning -- Unraisable exception
Exception ignored while finalizing socket <socket.socket fd=6, family=2, type=1, proto=6, laddr=('127.0.0.1', 49773)>:
ResourceWarning: unclosed <socket.socket fd=6, family=2, type=1, proto=6, laddr=('127.0.0.1', 49773)>
ok
The leaked object is a plain socket.socket, not an ssl.SSLSocket, which is what shows the failure happened before wrap_socket() took the file descriptor over: the only step in between that can raise while leaving self.sock assigned is that setsockopt() call. gh-110011 lists this test's ResourceWarning among others but does not identify the cause.
_tunnel() already handles its own connect-time failure by calling self.close() before raising. connect() should do the same when TCP_NODELAY cannot be set. I have a PR with the fix and a test.
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS
Linked PRs
- gh-157175
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
http.client.HTTPConnection.connect() から始め、TCP_NODELAY setsockopt() の失敗経路と、_tunnel() が接続時のエラーをどのように処理するかに重点を置いて確認します。test.test_ssl.TestPreHandshakeClose.test_https_client_non_tls_response_ignored と、その ResourceWarning の挙動を確認します。TCP_NODELAY の設定に失敗したときにソケットが閉じられ、関連するテストが未クローズのソケットに関する警告なしで成功すれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- backend, networking
- issue の種類
- バグ
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 活発さ
- 停滞
- 明瞭さ
- 明確に書かれている
- 初心者へのやさしさ
- 25/100