Deadlock under concurrent multithreaded use when DEBUG logging is enabled via setup_logging()
メンテナーはふだん 2 日以内に返信
@bewithgaurav がすでに取り組んでいます。
2026年7月10日 から。
評価
この issue はまだ評価されていません。
説明
Describe the bug
When driver logging is enabled via mssql_python.setup_logging(output="file") (DEBUG level) and multiple threads concurrently open connections and execute statements (for example a ThreadPoolExecutor with 4 workers), the process permanently deadlocks. It sits at 0% CPU — fully frozen, not merely slow.
The same code with setup_logging not called does not deadlock. It also does not deadlock with a single worker thread. The trigger is therefore the combination of DEBUG logging + concurrency (workers > 1).
Environment
- mssql-python version: 1.10.0
- Python version: 3.12.11
- Operating system: macOS (arm64)
- Authentication:
ActiveDirectoryDefault(Entra ID) against a Microsoft Fabric Warehouse. The deadlock is in the logging path and is very likely authentication-independent.
Observed thread stacks
Captured with Python's faulthandler. The dumps were identical across 7 dumps over roughly 7 minutes, which confirms a permanent deadlock rather than slowness.
Thread A (opening a connection):
File ".../mssql_python/connection.py", line 571 in setautocommit
File ".../mssql_python/connection.py", line 410 in __init__
File ".../mssql_python/db_connection.py", line 55 in connect
-> (calls into Python logging) ...
File ".../logging/handlers.py", line 75 in emit
File ".../logging/__init__.py", line 1144 in flush # blocked here
Thread B (executing a statement, a COPY INTO):
File ".../mssql_python/cursor.py", line 1545 in execute # blocked in native execute
Server-side check
While the client is frozen, the database server shows no query running for this session. This confirms the block is entirely client-side and is not waiting on the server.
Hypothesized mechanism
mssql-python emits DEBUG log records from within native code paths (for example setautocommit during connect, and cursor.execute) that hold the GIL / internal locks. Under concurrency this creates a lock-acquisition cycle with Python's logging Handler locks across threads:
- Thread A holds the logging handler lock and is blocked in
flush. - Thread B is blocked in native
executeand cannot proceed.
This is a classic logging-from-native-under-the-GIL deadlock. It only reproduces with workers > 1.
Steps to reproduce (minimal sketch)
- Call
mssql_python.setup_logging(output="file")to enable DEBUG logging. - From
N >= 2threads, concurrently open connections (autocommit=True) and run statements against the same server.
The process deadlocks within seconds to a couple of minutes.
Expected behavior
Enabling DEBUG logging should not affect correctness. Concurrent, multithreaded workloads should run to completion whether or not setup_logging is enabled.
Workaround
Do not enable setup_logging for concurrent / multithreaded workloads.
Impact
This makes the DEBUG logging feature unusable for any multithreaded application (for example parallel data-loading), which is precisely the scenario where enabling DEBUG logging is most valuable for diagnosis.
Possibly related issues
The following existing issues appear related but are distinct from this report:
- #540 — GIL held for the entire duration of
cursor.execute()(describes the native-call-holds-GIL behaviour that is part of the hypothesized mechanism here, but is about starvation rather than a permanent deadlock and does not involve logging). - #321 — multithreaded hang/deadlock with 3+ threads (does not involve logging; closed as non-reproducible).
- #421 — hang with
setup_loggingenabled (single-threaded, diagnosed as a driver-load hang on Linux rather than a concurrency logging-lock deadlock).
- 主要言語
- Python
- スター
- 478
- フォーク
- 62
- 平均マージ
- 3日 19分
- マージ済み PR（30日）
- 28
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/mssql-python のほかの issue
-
area: bulk-copy triage needed
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
microsoft/mssql-python#843 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
triage needed
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
microsoft/mssql-python#846 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
macOS: encrypted connections fail after Homebrew moved the `openssl` alias to `openssl@4`対応中かも @bewithgaurav が 14 日前に担当しました。 オープンarea: packaging-platform bug triage needed
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
microsoft/mssql-python#826 · コメント 2 件 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
-
Announcement: mssql-python is coming to Django through mssql-django 2.0再び着手できるかも @bewithgaurav が 41 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンannouncement
microsoft/mssql-python#748 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
-
Connection pool can briefly exceed max_size when pooling is disabled under load対応中かも @bewithgaurav が 24 日前に担当しました。 オープンarea: connectivity-auth bug triage done under development
難易度 4/5 3〜5日 初心者へのやさしさ 62/100
microsoft/mssql-python#746 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
microsoft/mssql-python の issue をすべて見る
似ている issue
-
good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
btclib-org/btclib-node#1955 ·
メンテナーはふだん 1 日以内に返信
-
documentation v0.9.2
難易度 2/5 半日 初心者へのやさしさ 72/100
khuisman/mcp-gee-sweet#1033 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
ossf/cve-bin-tool#5966 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 2 日以内に返信
-
write_iceberg ignores the table's write.parquet.compression-codec property対応中かも @YuangGao が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
Eventual-Inc/Daft#7606 ·
メンテナーはふだん 1 日以内に返信