Repository navigation
Validate NVRTC binary output capacities before native writes - #67
Draft
RicheyWorks wants to merge 1 commit into
Draft
RicheyWorks wants to merge 1 commit into
RicheyWorks wants to merge 1 commit into
Conversation
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.
The four byte-array NVRTC output wrappers read the Java array length but never use it. Native NVRTC getters have no capacity argument and write the complete compiler output. An empty or one-byte-short array therefore writes beyond the Java buffer;
-Xcheck:jnireproduces fatal bounds-check failures.Query the corresponding native output size before pinning the array, propagate size-query errors, and throw
IllegalArgumentExceptionwhen the Java capacity is insufficient. Check a failed critical-array acquisition before calling NVRTC. This covers CUBIN, deprecated NVVM, LTO IR and OptiX IR together as one output-capacity defect. Document the exception on the Java methods.24 isolated child JVM cases with
-Xcheck:jni: four formats times empty, one-byte-short, exact, padded, invalid program and null output. Eight undersized-buffer cases fail fatally against the published 12.6.0 JNI baseline; all 24 pass with the rebuilt JNvrtc and pristine upstream jcuda-common. Exact/padded outputs agree byte-for-byte, padded tails remain intact, rejected outputs remain unchanged, and invalid-program/null controls retain their behavior. Direct logged probes confirm the rebuilt DLL and small outputs (2472 bytes CUBIN/NVVM/LTO, 2516 bytes OptiX in this environment).CPU-only NVRTC 12.6.85 compiler work; generated code is never loaded or launched. Windows x86_64, Temurin22, existing MSVC/CMake, checksum-verified official CUDA12.6 workspace headers/import libraries and NVRTC DLLs. Maven uses the separately proposed Java8 compiler baseline in jcuda-parent PR2, excluded from this source change.
Make NVRTC DLLs available to the test process. No GPU context, allocation, reset, or ingestion pause; no full suite, cross-platform, concurrent program mutation, or large-output testing. Callers must still serialize compilation/program destruction against getters. This branch is independent of the lowered-name error fix in PR66. Upstream head/open PRs checked for overlap.