[NativeAOT] Objective-C exception propagation #80334

AustinWise · 2023-01-08T03:23:23Z

Related issue: #77472

This is the final part of the Objective-C Marshal API: the ability to turn a managed exception unwinding across a reverse-pinvoke boundary into a native exception.

The pieces to support this include:

If the first pass of exception unwinding hits a reverse-P/Invoke boundary, call a new classlib function to get the native callback.
After performing the second pass of unwinding, use a new RhpCallManagedToNativeExceptionCallback assembly helper to restore the context and jump to the native callback. This helper is based off of RhpCallCatchFunclet, with the calling of catch funclet and thread-abort handling removed.

Issues that need to be resolved before merging

Testing done

Built and tested with these commands for ARM64. Similar invocations for testing with X64.

./build.sh -ninja -s clr.aot+libs /p:TestNativeAot=true -c Release
./src/tests/build.sh -nativeaot -ninja Release -tree:Interop/ObjectiveC/ObjectiveCMarshalAPI
export CLRCustomTestLauncher=`pwd`/src/tests/Common/scripts/nativeaottest.sh
export CORE_ROOT=`pwd`/artifacts/tests/coreclr/OSX.arm64.Release/Tests/Core_Root
./artifacts/tests/coreclr/OSX.arm64.Release/Interop/ObjectiveC/ObjectiveCMarshalAPI/ObjectiveCMarshalAPI.sh

The test passes, which means the C++ exception dispatch code is able to unwind the stack after the new assembly helper restored the context. I added some extra asserts to check that the second pass unwind is done and that a value in the frame being restored is not clobbered after execution resumes. Specifically the assert(e == a) assert loads a from the stack in debug and the caller-saved x19 register in release. After jumping from the assembly helper to the native method that throws, the stack trace makes sense in the debugger (looks like CallAndCatch called ThrowInt or ThrowException).

I also tested this program continues to fail fast as expected on Windows:

using System;
using System.Runtime.InteropServices;

static class Program
{
    [UnmanagedCallersOnly]
    static void MyUnmanagedCallersOnlyFunction()
    {
        throw new Exception();
    }

    unsafe static void Main()
    {
        delegate* unmanaged<void> del = &MyUnmanagedCallersOnlyFunction;
        del();
    }
}

Known limitations

The prolog of the AMD64 assembly helper could preserve fewer registers.

The callback for exception unwinding expects a RuntimeMethodHandle that represents the managed method that was called via reverse P/Invoke. I tried doing this to convert the instruction pointer into a `RuntimeMethodHandle:

MethodBase? method = new StackFrame(ip, needFileInfo: false).GetMethod();
RuntimeMethodInfo? methodInfo = method as RuntimeMethodInfo;
RuntimeMethodHandle lastMethod = methodInfo?.MethodHandle ?? default;

For all the cases in the unit test, the StackFrame is unable to find the method object. I have not looked at this closely, but I believe this is because unmanaged-callers-only function and reverse-p/invoke stubs do not show up in the reflection invoke map. See this part of ILC for some possibly related UCO logic.

Since the code to lookup the RuntimeMethodHandle didn't work and Xamarin does not even use this value, I decided to remove the code and always set the RuntimeMethodHandle to 0.

ghost · 2023-01-08T03:23:35Z

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

Related issue: #77472

This is the final part of the Objective-C Marshal API: the ability to turn a managed exception unwinding across a reverse-pinvoke boundary into a native exception.

The pieces to support this include:

If the first pass of exception unwinding hits a reverse-P/Invoke boundary, call a new classlib function to get the native callback.
After performing the second pass of unwinding, use a new RhpCallManagedToNativeExceptionCallback assembly helper to restore the context and jump to the native callback. This helper is based off of RhpCallCatchFunclet, with the calling of catch funclet and thread-abort handling removed.

Issues that need to be resolved before merging

add AMD64 version of the assembly helper
Figure what to do about ThreadAbortException, which will be swallowed if it goes through this code path. Perhaps change RhpPInvokeReturn to check for pending thread aborts? Or maybe thread aborts don't matter since RhpInitiateThreadAbort is not called by anything?
Simplify the prolog of the ARM64 assembly helper, since it does not need to compatible with StackFrameIterator::UnwindFuncletInvokeThunk.

Known limitations

The callback for exception unwinding expects a RuntimeMethodHandle that represents the managed method that was called via reverse P/Invoke. I tried doing this to convert the instruction pointer into a `RuntimeMethodHandle:

MethodBase? method = new StackFrame(ip, needFileInfo: false).GetMethod();
RuntimeMethodInfo? methodInfo = method as RuntimeMethodInfo;
RuntimeMethodHandle lastMethod = methodInfo?.MethodHandle ?? default;

For all the cases in the unit test, the StackFrame is unable to find the method object. I have not looked at this closely, but I believe this is because unmanaged-callers-only function and reverse-p/invoke stubs do not show up in the reflection invoke map. See this part of ILC for some possibly related UCO logic.

Since the code to lookup the RuntimeMethodHandle didn't work and Xamarin does not even use this value, I decided to remove the code and always set the RuntimeMethodHandle to 0.

Author:	AustinWise
Assignees:	-
Labels:	`community-contribution`, `area-NativeAOT-coreclr`
Milestone:	-

AustinWise · 2023-01-08T03:46:46Z

@jankots
Does this general approach seem reasonable? If so, I'll add an AMD64 version of the assembly helper.

MichalStrehovsky · 2023-01-09T03:06:59Z

The callback for exception unwinding expects a RuntimeMethodHandle that represents the managed method that was called via reverse P/Invoke. I tried doing this to convert the instruction pointer into a `RuntimeMethodHandle:

It is not guaranteed that we'll be able to produce a RuntimeMethodHandle for an arbitrary function pointer.

One thing is that they need to go to the mapping table, which currently skips them. That should not be hard to fix (we just need to do the right thing when attempting to reflection-invoke this, which is why it's blocked - the right thing being "whatever CoreCLR does").

The other thing is that the compiler will only generate these mapping table entries for methods that are visible targets of reflection. We don't have the names/signatures of methods that are not visible targets of reflection. If this is only needed for UnmanagedCallersOnly methods, you could make them visible targets of reflection by making UnmanagedCallersOnly on apple platforms take codepath around here, I think:

runtime/src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/UsageBasedMetadataManager.cs

Lines 600 to 601 in 5da4a9e

    
           // Presence of code might trigger the reflectability dependencies. 
        
           if ((_generationOptions & UsageBasedMetadataGenerationOptions.CreateReflectableArtifacts) != 0)

It comes with size costs. It would be preferable if we don't need it.

src/coreclr/nativeaot/Runtime.Base/src/System/Runtime/ExceptionHandling.cs

jkotas · 2023-01-09T04:44:27Z

Does this general approach seem reasonable?

Yes, the approach looks reasonable.

Figure what to do about ThreadAbortException

You do not need to worry about ThreadAbortException. It is not supported.

The callback for exception unwinding expects a RuntimeMethodHandle

Xamarion iOS callback does not look at the RuntimeMethodHandle today: https://github.com/xamarin/xamarin-macios/blob/6e1ba31bae568ec54f53259e9e884f0550cfdae3/src/ObjCRuntime/Runtime.CoreCLR.cs#L144-L149 . It converts exceptions for all reverse PInvokes even the ones that have nothing to do with ObjectiveC interop (it is less than ideal). It should be ok to pass in default(RuntimeMethodHandle) here unless Xamarin iOS implementation changes.

jkotas · 2023-01-09T04:47:25Z

It should be ok to pass in default(RuntimeMethodHandle) here unless Xamarin iOS implementation changes.

We may want to consider introducing declarative scheme for this (mark all methods that want to participate in ObjectiveC interop with an attribute) to make this more pay-for-play and AOT friendly.

AustinWise · 2023-01-16T01:17:39Z

The test now passes on X64 too, after applying the same 8 byte offset to RSP that CoreCLR does:

https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/exceptionhandling.cpp#L4343-L4346

AustinWise · 2023-01-16T01:32:06Z

One thing I'm not sure is right is the back trace looks like this after jumping to ThrowInt in the test:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
  * frame #0: 0x0000000102018a6c libNativeObjCMarshalTests.dylib`(anonymous namespace)::ThrowInt(cxt=-121) at NativeObjCMarshalTests.cpp:104:32
    frame #1: 0x00000001002f98ac ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_Program__UCO_ThrowIntException + 76
    frame #2: 0x0000000102018b08 libNativeObjCMarshalTests.dylib`::CallAndCatch(fptr=(ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_Program__UCO_ThrowIntException), a=3423) at NativeObjCMarshalTests.cpp:131:9
    frame #3: 0x00000001002f903a ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_NativeObjCMarshalTests__CallAndCatch + 106
    frame #4: 0x00000001002f9d97 ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_Program___Validate_ExceptionPropagation + 551
    frame #5: 0x00000001002f9842 ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_Program__Validate_ReferenceTracking_Scenario + 882
    frame #6: 0x00000001002f9ef5 ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_Program__Main + 53
    frame #7: 0x00000001003ad1ff ObjectiveCMarshalAPI`ObjectiveCMarshalAPI__Module___MainMethodWrapper + 15
    frame #8: 0x00000001003ad27c ObjectiveCMarshalAPI`ObjectiveCMarshalAPI__Module___StartupCodeMain + 108
    frame #9: 0x00000001000073ef ObjectiveCMarshalAPI`main(argc=1, argv=0x00000003059f3788) at main.cpp:218:12
    frame #10: 0x0000000201902310 dyld`start + 2432

Notice the managed function UCO_ThrowIntException still show up in the stack trace after jumping to the propagation function. Compare to CoreCLR, where the managed function does not show up in the backtrace:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
  * frame #0: 0x000000010043fb94 libNativeObjCMarshalTests.dylib`(anonymous namespace)::ThrowInt(cxt=0x0000000000000d5f) at NativeObjCMarshalTests.cpp:105:9 [opt]
    frame #1: 0x000000010043fc0c libNativeObjCMarshalTests.dylib`::CallAndCatch(fptr=<unavailable>, a=3423) at NativeObjCMarshalTests.cpp:131:9 [opt]
    frame #2: 0x0000000118fbce1c
    frame #3: 0x0000000118fb7814
    frame #4: 0x0000000118fb0d98
    frame #5: 0x0000000102908f34 libcoreclr.dylib`CallDescrWorkerInternal + 132
    frame #6: 0x0000000102785284 libcoreclr.dylib`MethodDescCallSite::CallTargetWorker(unsigned long long const*, unsigned long long*, int) + 856
    frame #7: 0x000000010268bf4c libcoreclr.dylib`RunMain(MethodDesc*, short, int*, PtrArray**) + 656
    frame #8: 0x000000010268c228 libcoreclr.dylib`Assembly::ExecuteMainMethod(PtrArray**, int) + 396
    frame #9: 0x00000001026b3f94 libcoreclr.dylib`CorHost2::ExecuteAssembly(unsigned int, char16_t const*, int, char16_t const**, unsigned int*) + 616
    frame #10: 0x0000000102a3049c libcoreclr.dylib`coreclr_execute_assembly + 192
    frame #11: 0x0000000100005780 corerun`run(config=0x000000016fdff270) at corerun.cpp:429:18 [opt]
    frame #12: 0x0000000100002a88 corerun`main(argc=<unavailable>, argv=<unavailable>) at corerun.cpp:624:21 [opt]
    frame #13: 0x00000001a829be50 dyld`start + 2544

jkotas · 2023-01-16T06:02:38Z

One thing I'm not sure is right is the back trace looks like this after jumping to ThrowInt in the test:

Yes, it does not look right. All managed frames should be gone when the propagation function is called.

AustinWise · 2023-01-16T19:48:23Z

When I tried to step the StackFrameIterator past the reverse P/Invoke frame, I discovered that it skips directly from the reverse P/Invoke frame to the P/Invoke frame. This skips all the unmanaged frames in between:

https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/Runtime/unix/UnixNativeCodeManager.cpp#L293-L318

https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/Runtime/StackFrameIterator.cpp#L1450-L1458

So I added some hacks to allow the the StackFrameIterator to unwind into unmanaged code. The backtrace from the ThrowInt no longer shows the managed UCO_ThrowIntException function:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
  * frame #0: 0x00000001019679e0 libNativeObjCMarshalTests.dylib`(anonymous namespace)::ThrowInt(cxt=0x0000000000000d5f) at NativeObjCMarshalTests.cpp:105:9
    frame #1: 0x0000000101967a60 libNativeObjCMarshalTests.dylib`::CallAndCatch(fptr=(ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_Program__UCO_ThrowIntException), a=3423) at NativeObjCMarshalTests.cpp:131:9
    frame #2: 0x00000001002d7d60 ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_NativeObjCMarshalTests__CallAndCatch + 112
    frame #3: 0x00000001002d8bd8 ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_Program___Validate_ExceptionPropagation + 536
    frame #4: 0x00000001002d860c ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_Program__Validate_ReferenceTracking_Scenario + 876
    frame #5: 0x00000001002d8d90 ObjectiveCMarshalAPI`ObjectiveCMarshalAPI_ObjectiveCMarshalAPI_Program__Main + 48
    frame #6: 0x00000001003d344c ObjectiveCMarshalAPI`ObjectiveCMarshalAPI__Module___MainMethodWrapper + 12
    frame #7: 0x00000001003d34c0 ObjectiveCMarshalAPI`ObjectiveCMarshalAPI__Module___StartupCodeMain + 96
    frame #8: 0x000000010000cb50 ObjectiveCMarshalAPI`main(argc=1, argv=0x000000016fdff688) at main.cpp:218:12
    frame #9: 0x00000001a829be50 dyld`start + 2544

@jkotas What do you think of the idea enabling the StackFrameIterator to unwind into unmanaged code? It does not look like it was really designed with this in mind, so any ideas on how to more elegantly enable this would be appreciated.

jkotas · 2023-01-17T03:20:51Z

@jkotas What do you think of the idea enabling the StackFrameIterator to unwind into unmanaged code? It does not look like it was really designed with this in mind, so any ideas on how to more elegantly enable this would be appreciated.

Add a new StackFrameIterator::Flags that says whether to skips directly from the reverse P/Invoke frame to the P/Invoke frame. This flag should be set for GC stack walks, it should be cleared for EH stack walks. It will avoid need for the hacky IsEH method.
Add a new argument to the existing UnwindStackFrame method. I think it would look better than introducing a whole new method.

The memory in the CONTEXT structure was not being full initialized. Switching from using the transition frame to unwinding filled the stack with 0xDD values. When VS displayed the backtrace after calling RaiseFailFastException, it was corrupted (showing a selection of unrelated frames). This can reproduced on the main branch by changing the memset here to set 0xDD. So I think this a pre-existing problem.

AustinWise · 2023-01-22T04:37:13Z

This is now ready for review.

I noticed what appears to be a bug for Windows. When calling RaiseFailFastException on an unhanded exception, the CONTEXT parameter contains uninitialized stack memory. Depending on what bytes happen to be on the stack, the call stack displayed in Visual Studio after calling RaiseFailFastException is corrupted. Zero-initializing the CONTEXT appears to fix the problem. Perhaps this fix is worth backporting to .NET 7, since it is small in scope and could aid in diagnosing crashes.

jkotas

LGTM! @VSadov @janvorli @MichalStrehovsky Any additional feedback?

src/coreclr/nativeaot/Runtime/amd64/ExceptionHandling.S

src/coreclr/nativeaot/Runtime/EHHelpers.cpp

This reverts commit d2b5cd8.

MichalStrehovsky · 2023-01-23T07:51:37Z

LGTM! @VSadov @janvorli @MichalStrehovsky Any additional feedback?

Not my area of expertise, but looks good to me!

src/tests/Interop/ObjectiveC/ObjectiveCMarshalAPI/Program.cs

Co-authored-by: Jan Kotas <[email protected]>

VSadov · 2023-01-25T06:13:58Z

asm offsets on windows look incorrect

This reverts commit 89dd391.

AustinWise · 2023-01-26T05:33:42Z

asm offsets on windows look incorrect

Fixed; too bad that MSVC does not print the expression in static_assert.

VSadov · 2023-01-26T17:31:41Z

/azp run runtime-extra-platforms

azure-pipelines · 2023-01-26T17:32:04Z

Azure Pipelines successfully started running 1 pipeline(s).

VSadov

LGTM Thanks!

VSadov · 2023-01-26T21:31:00Z

The failures in extra-platforms do not look related to this change.

System.MissingMethodException : Constructor on type 'Microsoft.Extensions.Logging.LoggerFactoryOptions' not found.
   at System.Activator.CreateInstance[T]() + 0x94
   at Microsoft.Extensions.Options.OptionsFactory`1.Create(String) + 0x38
   at Microsoft.Extensions.Options.UnnamedOptionsManager`1.get_Value() + 0xb4
   at Microsoft.Extensions.Logging.LoggerFactory..ctor(IEnumerable`1 providers, IOptionsMonitor`1 filterOption, IOptions`1 options, IExternalScopeProvider scopeProvider) + 0xcc
   at Microsoft.Extensions.Logging!<BaseAddress>+0x78fce8
   at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0x14c
   at Internal.Reflection.Execution.MethodInvokers.InstanceMethodInvoker.Invoke(Object, Object[], BinderBundle, Boolean) + 0x60
   at Internal.Reflection.Core.Execution.MethodInvoker.Invoke(Object, Object[], Binder, BindingFlags, CultureInfo) + 0x54
   at System.Reflection.Runtime.MethodInfos.RuntimePlainConstructorInfo`1.Invoke(BindingFlags, Binder, Object[], CultureInfo) + 0xa8
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitRootCache(ServiceCallSite, RuntimeResolverContext) + 0x84
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(ServiceCallSite callSite, TArgument argument) + 0xe0
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.Resolve(ServiceCallSite, ServiceProviderEngineScope) + 0x34
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.CreateServiceAccessor(Type serviceType) + 0xec
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey, Func`2) + 0x9c
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.GetService(Type, ServiceProviderEngineScope) + 0x3c
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider, Type) + 0x64
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider) + 0x30
   at Microsoft.Extensions.Logging.Test.LoggerTest.Log_IgnoresExceptionInIntermediateLoggersAndThrowsAggregateException() + 0x70
   at Microsoft.Extensions.Logging!<BaseAddress>+0x73d730
   at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0xd8

MichalStrehovsky · 2023-01-27T12:38:21Z

The failures in extra-platforms do not look related to this change.

System.MissingMethodException : Constructor on type 'Microsoft.Extensions.Logging.LoggerFactoryOptions' not found.
   at System.Activator.CreateInstance[T]() + 0x94
   at Microsoft.Extensions.Options.OptionsFactory`1.Create(String) + 0x38
   at Microsoft.Extensions.Options.UnnamedOptionsManager`1.get_Value() + 0xb4
   at Microsoft.Extensions.Logging.LoggerFactory..ctor(IEnumerable`1 providers, IOptionsMonitor`1 filterOption, IOptions`1 options, IExternalScopeProvider scopeProvider) + 0xcc
   at Microsoft.Extensions.Logging!<BaseAddress>+0x78fce8
   at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0x14c
   at Internal.Reflection.Execution.MethodInvokers.InstanceMethodInvoker.Invoke(Object, Object[], BinderBundle, Boolean) + 0x60
   at Internal.Reflection.Core.Execution.MethodInvoker.Invoke(Object, Object[], Binder, BindingFlags, CultureInfo) + 0x54
   at System.Reflection.Runtime.MethodInfos.RuntimePlainConstructorInfo`1.Invoke(BindingFlags, Binder, Object[], CultureInfo) + 0xa8
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitRootCache(ServiceCallSite, RuntimeResolverContext) + 0x84
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(ServiceCallSite callSite, TArgument argument) + 0xe0
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.Resolve(ServiceCallSite, ServiceProviderEngineScope) + 0x34
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.CreateServiceAccessor(Type serviceType) + 0xec
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey, Func`2) + 0x9c
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.GetService(Type, ServiceProviderEngineScope) + 0x3c
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider, Type) + 0x64
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider) + 0x30
   at Microsoft.Extensions.Logging.Test.LoggerTest.Log_IgnoresExceptionInIntermediateLoggersAndThrowsAggregateException() + 0x70
   at Microsoft.Extensions.Logging!<BaseAddress>+0x73d730
   at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0xd8

I think it's from @vitek-karas change. I submitted a revert of his pr and it doesn't show these failures: #81259

MichalStrehovsky · 2023-01-31T04:46:47Z

This change broke something around unhandled exceptions on Windows.

With the Convenience Visual Studio repro project workflow from here: https://github.com/dotnet/runtime/blob/f1bdd5a6182f43f3928b389b03f7bc26f826c8bc/docs/workflow/building/coreclr/nativeaot.md#convenience-visual-studio-repro-project. Place a throw new Exception() in main.

Previously, the experience looked like this in the debugger:

Now it looks like this (note "Frame not in module" and a useless stack):

This change made it into the Preview 1 snap. Unless we roll back, unhandled exceptions are going to be undiagnosable in Preview 1, at least on Windows.

AustinWise · 2023-01-31T06:38:40Z

This change broke something around unhandled exceptions on Windows.

With the Convenience Visual Studio repro project workflow from here: https://github.com/dotnet/runtime/blob/f1bdd5a6182f43f3928b389b03f7bc26f826c8bc/docs/workflow/building/coreclr/nativeaot.md#convenience-visual-studio-repro-project. Place a throw new Exception() in main.

Previously, the experience looked like this in the debugger:

Now it looks like this (note "Frame not in module" and a useless stack):

This change made it into the Preview 1 snap. Unless we roll back, unhandled exceptions are going to be undiagnosable in Preview 1, at least on Windows.

This is should be fixed by #81010 .

AustinWise · 2023-01-31T07:02:26Z

@MichalStrehovsky Just to be clear, this problem was reproducible before this PR was merged. This PR incidentally has groomed the stack in a way that makes RaiseFailFastException unhappy when it reads the uninitialized memory.

#81010 should probably be considered for servicing for 7.0 as well.

MichalStrehovsky · 2023-01-31T07:06:06Z

My only gripe is that this is the first time I'm observing this failure mode and we just snapped 8.0 Preview 1 a couple hours ago, which means we're going to ship preview 1 like this. It's not the end of the world, but not great either.

Cc @agocke - see #80334 (comment)

AustinWise · 2023-01-31T07:25:52Z

Sorry about that. In retrospect I should have made sure the PR fixing the uninitialized memory read landed before this PR made the call stacks useless. I'll keep that principal in mind going forward.

ghost added the community-contribution Indicates that the PR has been added by a community member label Jan 8, 2023

dotnet-issue-labeler bot added the area-NativeAOT-coreclr label Jan 8, 2023

AustinWise mentioned this pull request Jan 8, 2023

[NativeAOT] Low level API support for Objective-C scenarios #77472

Closed

7 tasks

jkotas reviewed Jan 9, 2023

View reviewed changes

src/coreclr/nativeaot/Runtime.Base/src/System/Runtime/ExceptionHandling.cs Outdated Show resolved Hide resolved

AustinWise force-pushed the austin/NativeAotObjectiveCMarshal-Exception branch from 756568f to 5103dc6 Compare January 14, 2023 19:42

build-analysis bot mentioned this pull request Jan 15, 2023

Tracking issue for CI build timeouts #76454

Closed

This comment was marked as resolved.

Sign in to view

AustinWise force-pushed the austin/NativeAotObjectiveCMarshal-Exception branch from 9c8fac1 to 8758680 Compare January 16, 2023 00:41

runfoapp bot mentioned this pull request Jan 16, 2023

Infra improvements for Helix #68176

Closed

AustinWise mentioned this pull request Jan 21, 2023

[NativeAot] Objective-C Marshal: find method handle when propagating exceptions #80985

Open

[NativeAOT] Objective-C exception interception

dadbc7d

AustinWise force-pushed the austin/NativeAotObjectiveCMarshal-Exception branch from 1a523c7 to dadbc7d Compare January 21, 2023 23:59

AustinWise added 3 commits January 21, 2023 18:06

Fix Windows build

12f2484

Add back UnwoundReversePInvoke flag after re-initing.

fdbdd6b

AustinWise marked this pull request as ready for review January 22, 2023 04:30

AustinWise requested a review from MichalStrehovsky as a code owner January 22, 2023 04:30

jkotas approved these changes Jan 22, 2023

View reviewed changes

jkotas reviewed Jan 22, 2023

View reviewed changes

src/coreclr/nativeaot/Runtime/amd64/ExceptionHandling.S Show resolved Hide resolved

jkotas reviewed Jan 22, 2023

View reviewed changes

src/coreclr/nativeaot/Runtime/EHHelpers.cpp Outdated Show resolved Hide resolved

Revert "Fix backtrace in VS when calling RaiseFailFastException"

3866c20

This reverts commit d2b5cd8.

Switch to preemptive mode before jumping to propagation callback

b1a66d4

jkotas reviewed Jan 25, 2023

View reviewed changes

src/tests/Interop/ObjectiveC/ObjectiveCMarshalAPI/Program.cs Show resolved Hide resolved

Update src/tests/Interop/ObjectiveC/ObjectiveCMarshalAPI/Program.cs

8bee9f0

Co-authored-by: Jan Kotas <[email protected]>

Print actual and expected values in AsmOffsetsVerify.cpp

89dd391

build-analysis bot mentioned this pull request Jan 25, 2023

NuGet failing with Response status code does not indicate success: 503 (Service Unavailable) dotnet/arcade#11723

Open

5 tasks

This was referenced Jan 25, 2023

Test failure: System.Security.Cryptography.X509Certificates.Tests.CertificateCreation.CertificateRequestChainTests/CreateChain_Hybrid #25979

Closed

System.Security.Cryptography.X509Certificates.Tests.ChainTests.BuildInvalidSignatureTwice failure #65448

Closed

AustinWise added 2 commits January 25, 2023 20:53

Revert "Print actual and expected values in AsmOffsetsVerify.cpp"

c947c4b

This reverts commit 89dd391.

Fix windows AMD64 offsets.

95fae60

VSadov approved these changes Jan 26, 2023

View reviewed changes

jkotas merged commit 187508c into dotnet:main Jan 27, 2023

AustinWise deleted the austin/NativeAotObjectiveCMarshal-Exception branch January 28, 2023 05:33

ghost locked as resolved and limited conversation to collaborators Mar 2, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[NativeAOT] Objective-C exception propagation #80334

[NativeAOT] Objective-C exception propagation #80334

AustinWise commented Jan 8, 2023 •

edited

Loading

ghost commented Jan 8, 2023

Issues that need to be resolved before merging

Known limitations

AustinWise commented Jan 8, 2023

MichalStrehovsky commented Jan 9, 2023

jkotas commented Jan 9, 2023 •

edited

Loading

jkotas commented Jan 9, 2023

This comment was marked as resolved.

AustinWise commented Jan 16, 2023

AustinWise commented Jan 16, 2023

jkotas commented Jan 16, 2023

AustinWise commented Jan 16, 2023

jkotas commented Jan 17, 2023

AustinWise commented Jan 22, 2023

jkotas left a comment

MichalStrehovsky commented Jan 23, 2023

VSadov commented Jan 25, 2023

AustinWise commented Jan 26, 2023

VSadov commented Jan 26, 2023

azure-pipelines bot commented Jan 26, 2023

VSadov left a comment

VSadov commented Jan 26, 2023

MichalStrehovsky commented Jan 27, 2023

MichalStrehovsky commented Jan 31, 2023

AustinWise commented Jan 31, 2023

AustinWise commented Jan 31, 2023

MichalStrehovsky commented Jan 31, 2023

AustinWise commented Jan 31, 2023

[NativeAOT] Objective-C exception propagation #80334

[NativeAOT] Objective-C exception propagation #80334

Conversation

AustinWise commented Jan 8, 2023 • edited Loading

Issues that need to be resolved before merging

Testing done

Known limitations

ghost commented Jan 8, 2023

Issues that need to be resolved before merging

Known limitations

AustinWise commented Jan 8, 2023

MichalStrehovsky commented Jan 9, 2023

jkotas commented Jan 9, 2023 • edited Loading

jkotas commented Jan 9, 2023

This comment was marked as resolved.

AustinWise commented Jan 16, 2023

AustinWise commented Jan 16, 2023

jkotas commented Jan 16, 2023

AustinWise commented Jan 16, 2023

jkotas commented Jan 17, 2023

AustinWise commented Jan 22, 2023

jkotas left a comment

Choose a reason for hiding this comment

MichalStrehovsky commented Jan 23, 2023

VSadov commented Jan 25, 2023

AustinWise commented Jan 26, 2023

VSadov commented Jan 26, 2023

azure-pipelines bot commented Jan 26, 2023

VSadov left a comment

Choose a reason for hiding this comment

VSadov commented Jan 26, 2023

MichalStrehovsky commented Jan 27, 2023

MichalStrehovsky commented Jan 31, 2023

AustinWise commented Jan 31, 2023

AustinWise commented Jan 31, 2023

MichalStrehovsky commented Jan 31, 2023

AustinWise commented Jan 31, 2023

AustinWise commented Jan 8, 2023 •

edited

Loading

jkotas commented Jan 9, 2023 •

edited

Loading