Fix DispatchProxy pointer parameters and returns by caraioniurie47 · Pull Request #136452 · dotnet/runtime

caraioniurie47 · 2026-10-25T20:18:27Z

A DispatchProxy method generated for an interface method with a pointer parameter converted the pointer to object with castclass object on the raw pointer, so on CoreCLR a call with a non-null pointer usually threw NullReferenceException before Invoke ran, and Mono's JIT rejected the method with InvalidProgramException on every call. Pointer returns and ref/out pointer write-backs used castclass to the pointer type, so on CoreCLR a pointer returned by Invoke threw InvalidCastException.

Pointers now cross DispatchProxy.Invoke as follows:

A non-null pointer argument reaches Invoke in args as a System.Reflection.Pointer of the parameter's type (Pointer.Box); a null pointer reaches it as null, as on CoreCLR before this change. ref and in pointer arguments pass their current value the same way.
A pointer returned by Invoke, or written back to args for a ref/out pointer parameter, may be a Pointer, an IntPtr, or null for a null pointer. Anything else is unboxed as an IntPtr, so an int or a string throws InvalidCastException.
The pointer type stored in a returned Pointer is not checked, since Pointer exposes it only internally: a Pointer of long* returned for an int* gives its address. MethodInfo.Invoke rejects such a Pointer for an int* argument.

Apart from such a Pointer, MethodInfo.Invoke takes these forms for pointer arguments, and it returns a Pointer for a pointer return, so an Invoke that forwards with method.Invoke(target, args) works for pointer parameters passed by value and for pointer returns. For ref/out pointer parameters, the write-back works when Invoke sets args[i] itself. Forwarding a method with a ref, out or in pointer parameter through MethodInfo.Invoke still fails. This change leaves that as it is.

The conversions are C# methods in DispatchProxyGenerator that the generated proxies call directly; the proxy assembly gets an IgnoresAccessChecksTo attribute for System.Reflection.DispatchProxy once a proxy converts a pointer, as for internal proxied types. The IL generated for methods without pointers is unchanged, and so is the IL for function pointers.

The new tests in DispatchProxyTests cover pointer parameters, returns, ref/out/in pointers, void* and int**, forwarding through MethodInfo.Invoke, and pointer proxies in new AssemblyLoadContexts; the trimming test calls a pointer method.

Mono reads a proxy assembly's IgnoresAccessChecksTo attributes only once, so it misses one that a pointer proxy or a proxy of an internal type adds later; the new DispatchProxyTests tests are skipped on Mono, as asked in r4407294021.

Resolves #136451

Note

AI-generated, written at my direction and reviewed by me before posting.
Verified with this change on f0c7a08: DispatchProxy tests on Windows x64 CoreCLR, new ones failing without it; on Linux x64, CoreCLR with the trimming test and Mono JIT and interpreter, on an earlier version of the change.

The generated proxy method stored each argument in the object[] it passes to DispatchProxy.Invoke with Convert(paramType -> object), which for a pointer or function pointer fell through to `castclass object` on the raw pointer. A non-null pointer argument made the call throw NullReferenceException on CoreCLR before Invoke ran (or pass the pointee to Invoke as an object when its first word was a MethodTable pointer), and Mono rejected the method with InvalidProgramException on every call. Pointer returns and by-ref pointer write-backs had the same problem in the other direction (`castclass` to the pointer type). Box and unbox pointers in the forms MethodInfo.Invoke uses for pointer arguments and returns: a pointer argument reaches Invoke as a System.Reflection.Pointer of the parameter's type and a function pointer as an IntPtr; a pointer returned or written back by Invoke may be a Pointer (pointers only), an IntPtr or null (a null pointer), and anything else throws InvalidCastException. By-ref pointers are read and written with ldind.i/stind.i. The IL for every non-pointer parameter and return is unchanged. Fix dotnet#136451 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

azure-pipelines · 2026-10-25T20:19:10Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

dotnet-policy-service · 2026-10-25T20:19:36Z

Tagging subscribers to this area: @steveisok, @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

AaronRobinsonMSFT · 2026-10-25T21:05:41Z

Thanks for reporting this. Fixing the invalid IL for ordinary pointer parameters, returns, and ref/out write-back looks like the right thing to do, but I’d prefer to keep this PR narrowly focused on that.

Please remove the function-pointer support. I believe proxy creation still fails for those signatures on CoreCLR, and addressing that broader capability brings additional signature-encoding and cross-runtime support considerations that aren’t necessary to fix the reported issue.

For the ordinary pointer fix, please make the intended conversion contract explicit, particularly the change from null to a boxed null pointer, and accepting a Pointer whose stored type differs from the declared pointer type. Those choices become observable behavior we need to maintain. Please also distinguish custom interceptor write-back from forwarding through MethodInfo.Invoke(), whose existing by-reference pointer limitations remain outside this fix.

The goal here should be a bounded correctness fix, not a commitment to supporting every CLR signature through DispatchProxy.

jkotas · 2026-10-25T23:19:34Z

+                il.Emit(OpCodes.Conv_U);
+                il.Emit(OpCodes.Br_S, done);
+                il.MarkLabel(notNull);
+                il.Emit(OpCodes.Unbox_Any, typeof(IntPtr));


Does this match the conversion done by regular MethodInfo.Invoke for UIntPtr?

No. On CoreCLR, MethodInfo.Invoke takes an IntPtr for any pointer parameter and a UIntPtr only for void*; on Mono it takes a UIntPtr for any pointer parameter. The proxy takes an IntPtr back for any pointer type and, on CoreCLR, throws InvalidCastException for a UIntPtr. Matching CoreCLR would take a second unbox helper that also accepts a UIntPtr, used only for void* returns and write-backs. Should I add it?

jkotas · 2026-10-25T23:20:28Z

        private static readonly MethodInfo s_dispatchProxyInvokeMethod = typeof(DispatchProxy).GetMethod("Invoke", BindingFlags.NonPublic | BindingFlags.Instance)!;
        private static readonly MethodInfo s_getTypeFromHandleMethod = typeof(Type).GetMethod("GetTypeFromHandle", new Type[] { typeof(RuntimeTypeHandle) })!;
        private static readonly MethodInfo s_makeGenericMethodMethod = GetGenericMethodMethodInfo();
+        private static readonly MethodInfo s_pointerBoxMethod = typeof(Pointer).GetMethod(nameof(Pointer.Box))!;


This is going to be very rare path. It would be better to initialize these MethodInfos lazily.

Done in 8322ba2: with the conversions moved to C# (the other thread), the generator no longer looks up Pointer.Box and Pointer.Unbox; the two Func<>.Invoke methods it emits calls to are looked up on first use.

jkotas · 2026-10-25T23:22:11Z

+                }
+            }
+
+            // Unboxes a pointer from what MethodInfo.Invoke returns for one (a System.Reflection.Pointer for a pointer,


Where possible, it is better to write more complex logic like this in C# and just call the C# method instead of manually inlining the IL.

Done in 8322ba2: the conversions are now C# methods, BoxPointer and UnboxPointer in DispatchProxyGenerator. The generated code calls them through Func<> delegates held in two static fields of a PointerHelpers type, one per proxy assembly.

The proxies can't call the library's internal methods directly, and two other ways failed on Mono: IgnoresAccessChecksTo on the proxy assembly (Mono reads that attribute list once, so a pointer call before a proxy with an internal base type threw MethodAccessException), and [UnsafeAccessor] methods on an emitted type (Mono's TypeBuilder rejects a method without a body). With the delegates, the tests pass on CoreCLR, and passed on Mono, JIT and interpreter, before the last edits (comments, nameof, the load-context test). The trimming test now calls a pointer method.

Copilot

🔵 Needs a closer look

Cross-runtime pointer IL, conversion compatibility, and the Mono-only function-pointer path warrant final maintainer review.

No open issues 🎉

What changed in this PR

This PR fixes pointer argument and return handling in DispatchProxy by replacing invalid casts with explicit pointer conversions in generated IL.

Changes:

Adds Pointer and IntPtr conversions, including null handling and pointer-sized ref/out reads and writes.
Adds regression tests for ordinary, generic, and function pointers, plus reflection forwarding.
Enables unsafe test code; function-pointer tests exclude CoreCLR because of its existing signature-encoding limitation.

File	Description
src/libraries/System.Reflection.DispatchProxy/tests/TestTypes.cs	Adds pointer interfaces and forwarding implementations.
src/libraries/System.Reflection.DispatchProxy/tests/System.Reflection.DispatchProxy.Tests.csproj	Enables unsafe blocks for pointer tests.
src/libraries/System.Reflection.DispatchProxy/tests/DispatchProxyTests.cs	Tests pointer conversions, write-backs, and forwarding.
src/libraries/System.Reflection.DispatchProxy/src/System/Reflection/DispatchProxyGenerator.cs	Emits pointer boxing, unboxing, and indirect-access instructions.

_{Review effort: Balanced}

Leave function pointer parameters and returns as before: DispatchProxy.Create still throws for them on CoreCLR, where TypeBuilder can't encode function pointer types. A null pointer argument now reaches Invoke as null, as it did on CoreCLR before, instead of as a Pointer holding null. Convert pointers in two C# methods instead of inline IL. Generated proxies can't call the library's internal methods, so they call them through delegates held in static fields of a PointerHelpers type, defined once per proxy assembly. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

caraioniurie47 · 2026-10-26T18:18:06Z

@AaronRobinsonMSFT

Thanks for reporting this. Fixing the invalid IL for ordinary pointer parameters, returns, and ref/out write-back looks like the right thing to do, but I’d prefer to keep this PR narrowly focused on that....

Thanks, updated in 8322ba2, and the description now states the contract:

Function pointers are removed: their IL is as before, and the function pointer test is gone.
A null pointer argument now reaches Invoke as null, as it did on CoreCLR before this PR; a non-null pointer reaches it as a Pointer of the parameter's type.
Accepted back from Invoke (return or ref/out write-back): a Pointer, an IntPtr, or null as a null pointer; anything else is unboxed as an IntPtr, so an int or a string throws InvalidCastException. The pointer type stored in a Pointer isn't checked, since Pointer exposes it only internally.
ref/out write-back works when Invoke sets args[i] itself. Forwarding a method with a ref, out or in pointer parameter through MethodInfo.Invoke still fails; this PR doesn't change that.

jkotas · 2026-10-27T04:17:53Z

+        private static MethodInfo? s_unboxPointerInvokeMethod;
+
+        private static MethodInfo BoxPointerInvokeMethod =>
+            s_boxPointerInvokeMethod ??= typeof(Func<IntPtr, Type, object?>).GetMethod(nameof(Func<IntPtr, Type, object?>.Invoke))!;


Use field as the backing storage for lazily initialized properties

The next push moves the four lazily initialized properties this PR adds to field. One existing property in the file has the same pattern, DispatchProxyGenerator.cs:168-169:

internal ConstructorInfo IgnoresAccessChecksAttributeConstructor => _ignoresAccessChecksToAttributeConstructor ??= IgnoreAccessChecksToAttributeBuilder.AddToModule(_mb);

Should it move to field in this PR too?

Done in 747c7c8: the lazily initialized properties this PR adds use field. The two that return the delegate fields used to fill both fields from one helper type; each delegate now has a helper type of its own, so each property fills only its own backing field.

jkotas · 2026-10-27T04:25:37Z

+                Type helpers = tb.CreateType();
+
+                const BindingFlags Flags = BindingFlags.NonPublic | BindingFlags.Static;
+                helpers.GetField(nameof(BoxPointer), Flags)!.SetValue(null, new Func<IntPtr, Type, object?>(BoxPointer));


So these delegates always point to the same method. Why do we need them? Can these helper methods be called directly?

All the AI generated comments just rephrase what the code does in English. Such comments are not very useful.

Good comments explain why the code does what it does.

So these delegates always point to the same method. Why do we need them? Can these helper methods be called directly?

Not directly: the proxies live in a separate dynamic assembly, and BoxPointer and UnboxPointer aren't accessible outside System.Reflection.DispatchProxy, so a direct call needs IgnoresAccessChecksTo for it on the proxy assembly. Tested with the helpers internal, that passes on CoreCLR, but on Mono, JIT and interpreter, a pointer call followed by a proxy with an internal base type in the same load context throws MethodAccessException: Mono reads a dynamic assembly's IgnoresAccessChecksTo attributes only once, so it misses the one added later for the internal base type. A call through a delegate needs no IgnoresAccessChecksTo. If that Mono limitation is acceptable, I can switch to direct calls and drop the delegates.

Good comments explain why the code does what it does.

The next push also cuts or rewrites the comments that restate the code, and the delegates get a comment saying why. If the new comments look right, I'll do the same in #136450 and #136454. Thanks for the patience.

Done in 747c7c8: the comments that restated the code are removed or rewritten to say why.

The lazily initialized properties this change adds use the field keyword. The two that return the delegate fields used to fill both fields from one helper type; each delegate now has a helper type of its own, so each property fills only its own backing field. Comments that restated the code are removed or rewritten to say why. The load-context test is conditional on HasAssemblyFiles through ConditionalTheory, as tests.instructions.md asks; the older tests beside it return early instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CA1859 flagged the FieldInfo return type in the builds that run analyzers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

jkotas · 2026-10-28T23:50:47Z

+
+            // Proxies call BoxPointer and UnboxPointer through a delegate because they can't call them directly:
+            // the methods aren't accessible outside System.Reflection.DispatchProxy. IgnoresAccessChecksTo would
+            // allow the call on CoreCLR, but Mono reads a dynamic assembly's IgnoresAccessChecksTo attributes only


Mono is going to be deleted in near future. Workarounds for Mono bugs are not necessary - just disable the failing tests on Mono instead.

Done in 9cd377b: the proxies call BoxPointer and UnboxPointer directly; the delegates and their helper types are gone. A proxy that converts a pointer gets an IgnoresAccessChecksTo attribute for System.Reflection.DispatchProxy on its proxy assembly, through the existing EnsureTypeIsVisible. Mono reads a proxy assembly's IgnoresAccessChecksTo attributes only once, so it misses one that a pointer proxy or a proxy of an internal type adds later. The six pointer tests are skipped on Mono; without the skips they all failed there with MethodAccessException, on the JIT and the interpreter.

Proxies call BoxPointer and UnboxPointer directly instead of through delegates in helper types. A proxy that converts a pointer gets its proxy assembly an IgnoresAccessChecksTo attribute for System.Reflection.DispatchProxy, through EnsureTypeIsVisible, as for internal proxied types. Mono reads a dynamic assembly's IgnoresAccessChecksTo attributes only once, so it misses the one a pointer proxy or a proxy of an internal type adds later. The pointer tests are skipped on Mono. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dotnet-policy-service Bot added the community-contribution Indicates that the PR has been added by a community member label Oct 25, 2026

github-actions Bot added the area-System.Reflection label Oct 25, 2026

This was referenced Oct 25, 2026

System.Reflection.Emit can't call a generic method having a function pointer parameter #100020

Open

Copy custom modifiers in DispatchProxy overrides #135567

Merged

jkotas reviewed Oct 25, 2026

View reviewed changes

jkotas requested a balanced review from Copilot October 25, 2026 23:22

Copilot started reviewing on behalf of jkotas October 25, 2026 23:22

View session

Copilot AI reviewed Oct 25, 2026

View reviewed changes

caraioniurie47 requested a review from jkotas October 26, 2026 18:30

This was referenced Oct 26, 2026

Crash: access violation in coreclr!PgoManager::getPgoInstrumentationResults during tier-1 background JIT (Windows x86) #134695

Open

TensorExtensionsSpanInSpanOut<Single> test failure #135718

Open

jkotas reviewed Oct 27, 2026

View reviewed changes

caraioniurie47 and others added 2 commits October 27, 2026 23:20

Name the subject of two test comments

26fdcd3

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

build-analysis Bot mentioned this pull request Oct 28, 2026

[ci-scan] Hang: Abort_ConnectAndAbort_ThrowsWebSocketExceptionWithMessage times out on Windows #134806

Open

Return FieldBuilder from DefinePointerHelper

81325a9

CA1859 flagged the FieldInfo return type in the builds that run analyzers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

jkotas reviewed Oct 28, 2026

View reviewed changes

caraioniurie47 mentioned this pull request Oct 30, 2026

Write custom modifiers in PersistedAssemblyBuilder's order in CoreCLR's AssemblyBuilder #136699

Merged

Conversation

caraioniurie47 commented Oct 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

azure-pipelines Bot commented Oct 25, 2026

Uh oh!

dotnet-policy-service Bot commented Oct 25, 2026

Uh oh!

AaronRobinsonMSFT commented Oct 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🔵 Needs a closer look

Uh oh!

caraioniurie47 commented Oct 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

caraioniurie47 commented Oct 25, 2026 •

edited

Loading