Skip to content

TST: mark test_set_stats_level as thread_unsafe - #2782

Merged
lijinf2 merged 1 commit into
NVIDIA:mainfrom
lijinf2:fix/test-set-stats-level-thread-unsafe
Sep 9, 2026
Merged

TST: mark test_set_stats_level as thread_unsafe#2782
lijinf2 merged 1 commit into
NVIDIA:mainfrom
lijinf2:fix/test-set-stats-level-thread-unsafe

Conversation

@lijinf2

@lijinf2 lijinf2 commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

Summary

test_set_stats_level was missing the @pytest.mark.thread_unsafe marker, causing a flaky race condition when tests run in parallel. See CI log

Root Cause

cuFile's stats level is a process-global C library variable accessed via cufile.set_stats_level() / cufile.get_stats_level(). When test_set_stats_level runs concurrently with test_stats_start_stop (which explicitly calls set_stats_level(1)), the following race can occur:

test_set_stats_level        |  test_stats_start_stop
----------------------------|----------------------------
set_stats_level(0)          |
                            |  set_stats_level(1)   ← overwrites
get_stats_level() → 1       |
assert 1 == 0  ← FAILS      |

Fix

Add @pytest.mark.thread_unsafe(reason="cuFile stats level is process-global") to test_set_stats_level.

All other cuFile stats tests (test_stats_start_stop, test_get_stats_l1, test_get_stats_l2, test_get_stats_l3) were already marked thread_unsafe. This was an oversight introduced when those markers were added in #2218.

cuFile stats level is process-global state (a C library global
variable inside libcufile). Running test_set_stats_level concurrently
with test_stats_start_stop (which also calls set_stats_level(1)) can
cause a race condition where get_stats_level() returns the value set
by the other test, failing the assertion.

All other cuFile stats tests (test_stats_start_stop, test_get_stats_l1/l2/l3)
were already marked thread_unsafe; this commit fixes the oversight for
test_set_stats_level.
@copy-pr-bot

copy-pr-bot Bot commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@github-actions github-actions Bot added the cuda.bindings Everything related to the cuda.bindings module label Sep 8, 2026
@lijinf2 lijinf2 added the bug Something isn't working label Sep 8, 2026
@lijinf2 lijinf2 added this to the cuda.core 1.3.0 milestone Sep 8, 2026
@lijinf2
lijinf2 requested a review from seberg September 8, 2026 22:32
@lijinf2 lijinf2 self-assigned this Sep 8, 2026
@lijinf2

lijinf2 commented Sep 8, 2026

Copy link
Copy Markdown
Contributor Author

/ok to test ce46dec

@github-actions

This comment has been minimized.

@seberg seberg left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Could probably have guessed that this isn't thread-safe even if I didn't observe the flakiness :).

@lijinf2
lijinf2 merged commit 4aa48f5 into NVIDIA:main Sep 9, 2026
212 of 217 checks passed
@github-actions

github-actions Bot commented Sep 9, 2026

Copy link
Copy Markdown
Doc Preview CI
Preview removed because the pull request was closed or merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working cuda.bindings Everything related to the cuda.bindings module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants