You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
L4T Orin test_program.py::test_cuda_gdb_shows_nvrtc_debug_source_lines failures #2693
The previous run, with Sat Aug 22 12:48:14 AM IST 2026 had only 3 failures, as already reported under issue #2527.
This is the first run with 4 failures:
cuda-python Test Report
=======================
Board : local_l4t
Date : Sun Aug 23 12:48:06 AM IST 2026
Result : FAILED
--- Suite Results ---
cuda_pathfinder : 1327 passed, 0 failed, 1 skipped, 0 xfailed
cuda_bindings : 452 passed, 0 failed, 38 skipped, 0 xfailed
cuda_core : 3618 passed, 4 failed, 487 skipped, 2 xfailed
Total : 5397 passed, 4 failed, 2 xfailed
Note : xfailed = expected failures (known issues, marked xfail in tests)
--- Failures ---
FAILED cuda_core/tests/graph/test_graph_memory_resource.py::test_graph_alloc_with_output[global] - RuntimeError: Instantiation failed for an unexpected reason which is described in the return value of the function.
FAILED cuda_core/tests/graph/test_graph_memory_resource.py::test_graph_alloc_with_output[relaxed] - RuntimeError: Instantiation failed for an unexpected reason which is described in the return value of the function.
FAILED cuda_core/tests/graph/test_graph_memory_resource.py::test_graph_alloc_with_output[thread_local] - RuntimeError: Instantiation failed for an unexpected reason which is described in the return value of the function.
FAILED cuda_core/tests/test_program.py::test_cuda_gdb_shows_nvrtc_debug_source_lines - AssertionError: [Thread debugging using libthread_db enabled]
The new failure is:
FAILED cuda_core/tests/test_program.py::test_cuda_gdb_shows_nvrtc_debug_source_lines - AssertionError: [Thread debugging using libthread_db enabled]
codex gpt-5.6-sol ultra found:
The culprit is almost certainly PR #2679, merged between the Aug 22 and Aug 23 runs. It introduced the exact failing test at cuda_core/tests/test_program.py:1095, its helper, and the NVRTC source-materialization behavior being tested.
Confidence is very high that #2679 introduced the fourth test failure. The abbreviated assertion is insufficient to determine whether the implementation is broken on L4T or the new test needs an L4T-specific skip/probe.
test_graph_alloc_with_output[global|relaxed|thread_local] fail at graph instantiation with:
RuntimeError: Instantiation failed for an unexpected reason which is described in the return value of the function.
This is CUDA_GRAPH_INSTANTIATE_ERROR when GraphCompleteOptions(auto_free_on_launch=True) is used. Same failures reported since Aug 7 in #2527. The test skips on CUDA_ERROR_INVALID_VALUE but L4T returns a generic instantiate error instead.
Unit tests for temp-file creation (likely pass on L4T)
Integration test test_cuda_gdb_shows_nvrtc_debug_source_lines
The L4T assertion message:
AssertionError: [Thread debugging using libthread_db enabled]
indicates cuda-gdb started but produced almost no useful output — no temp .cu path and no ISSUE_2422_SOURCE_LINE from list.
Likely cause: the NVRTC materialization implementation is probably fine on L4T; the cuda-gdb integration test is fragile on embedded/CI environments. It requires cuda-gdb to break on kernel launch and show NVRTC debug source lines on aarch64/Tegra, which may not work in the L4T CI setup (ptrace restrictions, cuda-gdb Jetson limitations, or silent early exit).
Probe results (x86 RunPod sanity check, CTK 13.3)
Ran a diagnostic probe on x86 (RTX 4090) — cannot emulate L4T aarch64, but confirms:
Check
Result
NVRTC temp file materialization (debug=True)
PASS
cuda-gdb 13.3 present
PASS
cuda-gdb list shows source lines
Inconclusive on RunPod (driver/CTK version mismatch)
NVRTC writes temp files like /tmp/cuda_gdb_src_kernel_XXXXXXXX.cu with correct content when debug=True and no explicit name=.
Recommendations
Improve test diagnostics — on failure, log full cuda-gdb stdout/stderr + returncode (current assertion truncates to banner-only output).
Consider L4T skip/xfail for the gdb integration test until break-on-launch works on Jetson CI; keep the unit tests for materialization.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after vfork from child process 5755]
[New Thread 0x7cd11a7ff640 (LWP 5756)]
...
Output tail (relevant errors):
Cuda Driver error detected: CUDA binary (cubin) ELF section '.note.nv.cuver' is missing.
Cuda Driver error detected: Returning 200 (CUDA_ERROR_INVALID_IMAGE) from cuLibraryLoadData
warning: Error disabling address space randomization: Operation not permitted
Traceback (most recent call last):
File "/tmp/tmpmzg25hgh_cuda_gdb_src.py", line 17, in main
k = mod.get_kernel("kernel")
cuda.core._utils.cuda_utils.CUDAError: CUDA_ERROR_INVALID_IMAGE
Note: RunPod driver 575 supports CUDA 12 max while probe used CTK 13.3 bindings — the CUDA_ERROR_INVALID_IMAGE is a RunPod environment artifact, not the L4T failure mode. On L4T with matching CTK 13.3 driver, the failure presents as banner-only output (matching the CI assertion).
L4T CI failure (from issue report, for comparison)
FAILED cuda_core/tests/test_program.py::test_cuda_gdb_shows_nvrtc_debug_source_lines
AssertionError: [Thread debugging using libthread_db enabled]
This is consistent with cuda-gdb starting but never reaching kernel breakpoint / list output with the materialized .cu source path.
Probe script (scripts/issue2693-l4t-probe.py)
Run on the L4T board (or any CUDA host with cuda.core installed):
To close the loop here, this is the first passing job after this fix (there were some other unrelated issues in the meantime that needed to be resolved separately):
cuda-python Test Report
=======================
Board : local_l4t
Date : Tue Sep 1 11:37:20 AM IST 2026
Result : PASSED
--- Suite Results ---
cuda_pathfinder : 1612 passed, 0 failed, 2 skipped, 0 xfailed
cuda_bindings : 454 passed, 0 failed, 36 skipped, 0 xfailed
cuda_core : 3714 passed, 0 failed, 472 skipped, 3 xfailed
Total : 5780 passed, 0 failed, 3 xfailed
Note : xfailed = expected failures (known issues, marked xfail in tests)
Log file : 20260901_111652.log
Activity
atiaomar1978-hub commentedon Aug 25, 2026
Investigation summary
Investigated the four L4T Orin failures (CTK 13.3, Aug 23 run). These split into two independent root causes.
1. Three graph failures — pre-existing (#2527)
test_graph_alloc_with_output[global|relaxed|thread_local]fail at graph instantiation with:This is
CUDA_GRAPH_INSTANTIATE_ERRORwhenGraphCompleteOptions(auto_free_on_launch=True)is used. Same failures reported since Aug 7 in #2527. The test skips onCUDA_ERROR_INVALID_VALUEbut L4T returns a generic instantiate error instead.Not caused by PR #2679.
2. One new gdb failure — introduced by PR #2679
PR #2679 (merged Aug 21) added NVRTC debug source materialization (
_try_materialize_nvrtc_debug_source) plus:test_cuda_gdb_shows_nvrtc_debug_source_linesThe L4T assertion message:
indicates cuda-gdb started but produced almost no useful output — no temp
.cupath and noISSUE_2422_SOURCE_LINEfromlist.Likely cause: the NVRTC materialization implementation is probably fine on L4T; the cuda-gdb integration test is fragile on embedded/CI environments. It requires cuda-gdb to break on kernel launch and show NVRTC debug source lines on aarch64/Tegra, which may not work in the L4T CI setup (ptrace restrictions, cuda-gdb Jetson limitations, or silent early exit).
Probe results (x86 RunPod sanity check, CTK 13.3)
Ran a diagnostic probe on x86 (RTX 4090) — cannot emulate L4T aarch64, but confirms:
debug=True)listshows source linesNVRTC writes temp files like
/tmp/cuda_gdb_src_kernel_XXXXXXXX.cuwith correct content whendebug=Trueand no explicitname=.Recommendations
Logs
Probe script:
scripts/issue2693-l4t-probe.py(RunPod runner:scripts/runpod-issue2693-probe.sh)Probe summary (2026-08-25, x86_64 RunPod RTX 4090, CTK 13.3.0)
Platform / toolkit
NVRTC debug materialization (PASS)
{ "case": "debug_implicit_name", "compiled_name": "/tmp/issue2693_probe_probe_kernel_vp4p7e82.cu", "basename": "issue2693_probe_probe_kernel_vp4p7e82.cu", "file_exists_at_compile": true, "content_has_marker": true, "basename_matches_pattern": true }Helper kernel (mirrors
cuda_gdb_src.py):{ "compiled_name": "/tmp/issue2693_probe_kernel_42wws4_y.cu", "basename": "issue2693_probe_kernel_42wws4_y.cu", "file_exists_at_compile": true, "matches_gdb_test_pattern": true }cuda-gdb session (integration path — no source lines on RunPod)
Output head:
Output tail (relevant errors):
L4T CI failure (from issue report, for comparison)
This is consistent with cuda-gdb starting but never reaching kernel breakpoint /
listoutput with the materialized.cusource path.Probe script (
scripts/issue2693-l4t-probe.py)Run on the L4T board (or any CUDA host with
cuda.coreinstalled):export ISSUE2693_PROBE_JSON=/tmp/issue2693-l4t-probe.json python3 scripts/issue2693-l4t-probe.py cat /tmp/issue2693-l4t-probe.jsonFull probe script (click to expand)
lijinf2 commentedon Aug 25, 2026
Thank you @rwgk ! I will take a look.
fix(cuda.core): xfail cuda-gdb test where GPU debugging is unavailable (
rwgk commentedon Sep 1, 2026
To close the loop here, this is the first passing job after this fix (there were some other unrelated issues in the meantime that needed to be resolved separately):