Fix native library loader silently failing when CUDA DLLs are missing#1555
Open
alinpahontu2912 wants to merge 5 commits intodotnet:mainfrom
Open
Fix native library loader silently failing when CUDA DLLs are missing#1555alinpahontu2912 wants to merge 5 commits intodotnet:mainfrom
alinpahontu2912 wants to merge 5 commits intodotnet:mainfrom
Conversation
Change all 'ok = TryLoadNativeLibraryByName(...)' calls to 'ok &= ...' so that failures accumulate instead of being overwritten by subsequent successful loads. Initialize 'ok = true' before the loading chain. Previously, each load call overwrote the result of the previous one, so if an early CUDA dependency (e.g. cudnn_adv64_9) failed to load but LibTorchSharp succeeded, 'ok' would be true. This caused: - nativeBackendCudaLoaded set to true despite missing dependencies - The fallback loading path was skipped - The diagnostic trace (StringBuilder) was discarded - Subsequent load attempts were skipped entirely - CUDA operations failed later with cryptic errors Now any single load failure keeps 'ok' as false, ensuring the fallback path is attempted and the full diagnostic trace is preserved in error messages. Fixes dotnet#1545 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Change all 'ok = TryLoadNativeLibraryByName(...)' calls to 'ok &= ...' so that failures accumulate instead of being overwritten by subsequent successful loads. Initialize 'ok = true' before the loading chain. Previously, each load call overwrote the result of the previous one, so if an early CUDA dependency (e.g. cudnn_adv64_9) failed to load but LibTorchSharp succeeded, 'ok' would be true. This caused: - nativeBackendCudaLoaded set to true despite missing dependencies - The fallback loading path was skipped - The diagnostic trace (StringBuilder) was discarded - Subsequent load attempts were skipped entirely - CUDA operations failed later with cryptic errors Now any single load failure keeps 'ok' as false, ensuring the fallback path is attempted and the full diagnostic trace is preserved in error messages. Fixes dotnet#1545 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
alinpahontu2912
force-pushed
the
fix/cuda-dll-silent-load-failure
branch
from
340f948 to
c7f1271
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a correctness issue in TorchSharp’s native library loader where a failed CUDA dependency load could be overwritten by later successful loads, causing the loader to incorrectly treat the CUDA backend as initialized and skip the fallback/diagnostics path.
Changes:
- Initialize
oktotruebefore the native-load attempt chain. - Accumulate load results using
ok &= TryLoadNativeLibraryByName(...)so any single failure preservesok == falsewhile still attempting all loads (capturing full diagnostics).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…/alinpahontu2912/TorchSharp into fix/cuda-dll-silent-load-failure
The previous fix changed simple assignments (ok =) to compound AND (ok &=) for all native library loads. This broke CPU-only systems because torch_cuda failing would permanently set ok=false, even when LibTorchSharp loaded successfully, triggering a NotSupportedException. Changes: - CUDA preloads (cudnn, nvrtc, etc.): fire-and-forget, failures are non-fatal and only logged via trace - torch_cuda / torch_cpu: fire-and-forget warmup loads for dependency resolution; their result doesn't gate success - LibTorchSharp: the only critical load that determines ok - TryInitializeDeviceType: catch NotSupportedException to prevent static constructor crashes - Static constructor: fall back to CPU backend when CUDA is unavailable Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change all 'ok = TryLoadNativeLibraryByName(...)' calls to 'ok &= ...' so that failures accumulate instead of being overwritten by subsequent successful loads. Initialize 'ok = true' before the loading chain.
Previously, each load call overwrote the result of the previous one, so if an early CUDA dependency (e.g. cudnn_adv64_9) failed to load but LibTorchSharp succeeded, 'ok' would be true. This caused:
Now any single load failure keeps 'ok' as false, ensuring the fallback path is attempted and the full diagnostic trace is preserved in error messages.
Fixes #1545