Repository navigation
Tensor<T> slice pinning starts at the parent array instead of the slice #134691
Description
Activity
- addeduntriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner
on Sep 26, 2026 dotnet-policy-service commented
on Sep 26, 2026 ContributorMore actionsTagging subscribers to this area: @dotnet/area-system-numerics-tensors
See info in area-owners.md if you want to be subscribed.I confirmed a downstream impact while validating the proposed ONNX Runtime fix in PR #25972, discussed in onnxruntime#25460.
I'm building a .NET embeddings pipeline and exploring direct interoperability between System.Numerics.Tensors and ONNX Runtime. The proposed ORT bridge uses the public pinning API for dense tensors. This issue causes it to pass the correct shape but the wrong values to native inference when the tensor is a contiguous slice with a nonzero offset.
For example, a
[2,2]slice starting at element 2 of[91,92,11,12,21,22]produces native Identity output[91,92,11,12]instead of[11,12,21,22]. A Float32 slice exhibits the same problem.To isolate the cause, I built the original Tensors project at 5eaa18a, the runtime component revision corresponding to the 10.0.9 package. The unmodified source reproduces both failures. I then applied a local one-line candidate correction that includes
_startwhenGetPinnableReference()returns the first-element reference.With the same ORT PR binary, native runtime, and inputs, the result changed from 15/17 to 17/17 correct native-inference outputs. Both contiguous-slice failures disappeared. The dense input still aliases the original slice, so this wasn't resolved by introducing a copy. The pin-handle ownership and disposal code remained unchanged.
The experiment used ORT PR commit 3553884, released CPU native ORT 1.23.2, and .NET 10.0.12 on Windows x64. An additional 40 direct pinning probes passed with the candidate, covering roots, offset and nested slices, empty tensors, and pinned/unpinned storage.
This is a local candidate, not an accepted or released runtime fix. It confirms that this issue blocks correct direct contiguous-slice interoperability in the proposed ORT bridge, rather than ONNX Runtime inference generally. Stable Memory binding remains a working alternative and passed every control case.
- removeduntriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner
on Sep 30, 2026 - added a commit that references this issue
on Sep 30, 2026 - added a commit that references this issue
on Oct 6, 2026
Description
A contiguous
Tensor<long>slice returns different values through its pinning APIs than through its indexer or tensor span. WithSystem.Numerics.Tensors10.0.9,GetPinnableReference()andGetPinnedHandle()start at the parent array rather than the beginning of the slice.Scenario
I'm prototyping a .NET ONNX text-embedding pipeline. I want to use tensors through preprocessing, inference, and postprocessing, including passing contiguous slices to native inference without another data copy.
The shape is correct, but the pointer addresses the wrong part of the data. That means a native consumer can receive different inputs without a shape error. The repro below removes ONNX and the rest of my application. It only needs
System.Numerics.Tensors.Configuration
System.Numerics.Tensors10.0.9net10.0; NativeAOT explicitly disabledReproduction Steps
You can find the runnable file-based app and captured output in this gist. The complete code is also included below.
Save the following as
TensorSlicePinning.csin a new directory outside a repository. File-based apps inherit project settings from parent directories.dotnet run --file .\TensorSlicePinning.csActual behavior
Compilation succeeds. Running the app produces the following output and exits with code
1:Expected behavior
The reference and pointer should start at
11, the first element of the slice. Reading four elements should return[11,12,21,22], matching the indexer and tensor span. The app should exit with code0.1111[11,12,21,22][11,12,21,22]GetPinnableReference()1191GetPinnedHandle()[11,12,21,22][91,92,11,12]01Other information
All pointer reads happen while the
MemoryHandleis alive and stay within the allocated six-element array.In the 10.0.9 source,
Slicerecords_start, butGetPinnableReference()appears to return the array's first element without applying that offset.GetPinnedHandle()uses that reference. This looks related to the behavior above.I've reproduced this on the configuration listed above. I haven't checked other versions or platforms.