Logger: stale config guard can reset a newer configuration, and resets sinks without the mutex
メンテナーはふだん 1 日以内に返信
@kaatish がすでに取り組んでいます。
2026年8月31日 から。
評価
この issue はまだ評価されていません。
説明
logger_config_guard's destructor resets the logger unconditionally and without holding g_guard_mutex (cpp/src/utilities/logger.cpp:141-142, and reset_default_logger at :127-130):
struct logger_config_guard {
~logger_config_guard() { cuopt::reset_default_logger(); }
};
Two problems, both on main today.
A stale guard can reset a newer configuration. A guard's refcount reaching zero expires g_active_guard before the destructor body runs. In that window another thread calling init_logger_t sees no live configuration, applies its own and installs a new guard. The first destructor then runs and resets the logger out from under it, so that thread's messages go to the buffer sink and are dropped while it still holds a live handle.
Unsynchronized sink mutation. reset_default_logger does sinks().clear() / push_back() with no lock, while init_logger_t's configure path mutates the same vector under g_guard_mutex (:151, :160-168). Two threads can mutate it concurrently.
Reproducing
Needs the refcount to hit zero exactly while another thread is inside the configure path. Under contention g_active_guard.lock() usually succeeds instead, so the window is rarely entered and a straightforward stress test does not reliably hit it. A TSAN build over concurrent solves that each construct an init_logger_t is the more likely way to surface the sink mutation.
Suggested fix
Give each configuration a generation number, record it in the guard, and have the destructor take g_guard_mutex and reset only if its own generation is still current. That closes the stale-reset window and puts sink mutation on the configure and reset paths under the same lock.
Exposure is limited in practice: configuration happens at solve boundaries rather than concurrently with a solve that is emitting. Split out of #1778, which found it but where the fix was out of scope.
- 主要言語
- Cuda
- スター
- 1.1k
- フォーク
- 255
- 平均マージ
- 1日 22時間
- マージ済み PR（30日）
- 102
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
NVIDIA/cuopt のほかの issue
-
[BUG] Constraint validation reports CSR offset count as the number of rows対応中かも @0z5a が 2 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
ci: pr-test-summary job shows red when the GitHub API returns persistent 5xx errors対応中かも @0z5a が 2 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
bug mip
難易度 4/5 1〜2日 初心者へのやさしさ 53/100
NVIDIA/cuopt#2290 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] Dataset downloader reports success and replaces data after a failed download対応中かも @0z5a が 2 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信