[CI/Build][ROCm] Run the TileLang HIP symbol checks in their own interpreter - #53117
Conversation
…rpreter test_mhc_tilelang_jit.py asserts that TileLang stays out of sys.modules and that hipFree still resolves to libamdhip64, so that the libhip_stub.so TileLang ships never takes the symbol over. Both claims are about process-global state, and the neighbouring test_mhc_kernels.py legitimately imports TileLang to exercise those kernels, so in a whole-directory run there is nothing left to assert and the test fails. Move the checks into a script that the test runs in a fresh interpreter, which keeps them meaningful regardless of what the rest of the suite imports. Signed-off-by: Stefan Koncarevic <Stefan.Koncarevic@amd.com>
|
/ci run |
|
✅ Triggered Buildkite CI #84851 for commit |
| @@ -0,0 +1,60 @@ | |||
| #!/usr/bin/env python3 | |||
There was a problem hiding this comment.
Do we need a separate file for this?
There was a problem hiding this comment.
The subprocess is the point of the change, and I put the script in a file to
follow what is already in the tree: tests/cuda/test_platform_no_cuda_init.py
keeps its checks in tests/cuda/scripts/check_*.py and runs them the same way,
with subprocess.run([sys.executable, str(script_path)]) and a pytest.fail on
a non-zero exit.
The alternative is to inline the source as a string and pass it with python -c,
as tests/config/test_config_utils.py does, but this check needs a ctypes
structure and the dlsym/dladdr calls, and inside a string none of that is
formatted or linted. I can switch if you prefer no new file in the tree.
|
/ci run |
|
✅ Triggered Buildkite CI #85096 for commit |
The test belongs to the Kernels Root Misc Test group, which AMD CI does not run yet.
This fix should land before the PR that enables that group (#50519).
Purpose
test_deepseek_v4_import_and_jit_monitor_do_not_hijack_hip_symbolsasserts twothings about process-global state: that importing DeepSeek V4 and activating the
JIT monitor leaves TileLang out of
sys.modules, and thathipFreein theglobal symbol table still resolves to
libamdhip64.sorather than thelibhip_stub.soTileLang ships.On its own the test holds. In a whole-directory run it does not, because the
sibling
test_mhc_kernels.pyimports TileLang on purpose to exercise thosekernels. By the time this test runs, TileLang is already in
sys.modulesandits stub is already loaded, so the test fails on suite-wide state rather than on
anything about the code it is guarding.
Move the two checks into
tests/kernels/scripts/check_no_tilelang_hijack.pyandhave the test run it with
sys.executable. In a fresh interpreter theassertions mean what they say no matter what the rest of the suite imports, and
the test reports the script's output when it fails.
Test Plan
Run the two files together, in the order a whole-directory collection gives
them:
Test Result
On MI355 (gfx950, ROCm 7.2.3), before the change, the sibling import is enough
to take the test down:
After:
The check still bites when the symbols really are taken over. Running the script
in an interpreter that has TileLang loaded fails it, as it should:
Essential Elements of an Effective PR Description Checklist
supported_models.mdandexamplesfor a new model.