[NativeAOT] correctly initalize CONTEXT before failing fast by AustinWise · Pull Request #81010 · dotnet/runtime

AustinWise · 2023-01-23T03:35:51Z

Short Explanation

Basically the CONTEXT structure is not being initalized properly before calling RaiseFailFastException.

Long Explanation

Consider this program:

usingSystem;usingSystem.Globalization;staticclassProgram{staticvoidFillStack(bytevalue){Span<byte>bytes=stackallocbyte[1024*16];bytes.Fill(value);}staticvoidMain(string[]args){if(args.Length!=0){bytefillValue=byte.Parse(args[0],NumberStyles.HexNumber);AppDomain.CurrentDomain.UnhandledException+=(_,_)=>FillStack(fillValue);}thrownewException();}}

On NativeAOT on Windows, the last act of a process that throws an unhanded exception is to call RaiseFailFastExceptionhere. The instruction pointer and CONTEXT structure passed to RaiseFailFastException point at the function that raised the unhanded exception. If you have a debugger like Visual Studio attached after when RaiseFailFastException is called, you will see a call stack pointing to the faulting function.

Depending on what argument you pass to the program, you get different call stacks.

If you pass 0 you get:

 ntdll.dll!NtRaiseException�()	Unknown
KernelBase.dll!RaiseFailFastException�()	Unknown
reproNative.exe!S_P_CoreLib_Interop_Kernel32__RaiseFailFastException_0�()	Unknown
>	reproNative.exe!S_P_CoreLib_Interop_Kernel32__RaiseFailFastException() Line 46	Unknown
reproNative.exe!S_P_CoreLib_System_RuntimeExceptionHelpers__FailFast_1() Line 279	Unknown
reproNative.exe!S_P_CoreLib_System_RuntimeExceptionHelpers__RuntimeFailFast() Line 219	Unknown
reproNative.exe!S_P_CoreLib_System_Runtime_EH__UnhandledExceptionFailFastViaClasslib() Line 205	Unknown
reproNative.exe!S_P_CoreLib_System_Runtime_EH__DispatchEx() Line 650	Unknown
reproNative.exe!S_P_CoreLib_System_Runtime_EH__RhThrowEx() Line 572	Unknown
reproNative.exe!RhpThrowEx() Line 190	Unknown
reproNative.exe!repro_Program__Main() Line 24	Unknown
reproNative.exe!repro__Module___MainMethodWrapper()	Unknown
reproNative.exe!repro__Module___StartupCodeMain()	Unknown
reproNative.exe!wmain(int argc, wchar_t * * argv) Line 216	C++
reproNative.exe!invoke_main() Line 91	C++
reproNative.exe!__scrt_common_main_seh() Line 288	C++
reproNative.exe!__scrt_common_main() Line 331	C++
reproNative.exe!wmainCRTStartup(void * __formal) Line 17	C++
kernel32.dll!BaseThreadInitThunk()	Unknown
ntdll.dll!RtlUserThreadStart�()	Unknown

That's less than ideal as it does not directly point at the faulting function.

If you pass ff you get garbage:

 00000000f2d49ff1()	Unknown
000001ed07011578()	Unknown
000001ed07011548()	Unknown
>	reproNative.exe!repro_Program___c__DisplayClass1_0___Main_b__0() Line 22	Unknown

After this PR is merged, the call stack correctly points at the faulting function:

>	reproNative.exe!repro_Program__Main() Line 24	Unknown
reproNative.exe!repro__Module___MainMethodWrapper()	Unknown
reproNative.exe!repro__Module___StartupCodeMain()	Unknown
reproNative.exe!wmain(int argc, wchar_t * * argv) Line 216	C++
reproNative.exe!invoke_main() Line 91	C++
reproNative.exe!__scrt_common_main_seh() Line 288	C++
reproNative.exe!__scrt_common_main() Line 331	C++
reproNative.exe!wmainCRTStartup(void * __formal) Line 17	C++
kernel32.dll!BaseThreadInitThunk()	Unknown
ntdll.dll!RtlUserThreadStart�()	Unknown

TODO before merging:

~~AMD64: capture CS, SS, and RFLAGS into PAL_LIMITED_CONTEXT when throwing and exception~~
~~AMD64: restore CS, SS, and RFLAGS in RhpCopyContextFromExInfo~~
In RhpCopyContextFromExInfo, capture the CS and SS segment registers from the current thread and stuff them into the CONTEXT.

ghost · 2023-01-23T03:36:03Z

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

Issue Details

Short Explanation

Basically the CONTEXT structure is not being initalized properly before calling RaiseFailFastException.

Long Explanation

Consider this program:

usingSystem;usingSystem.Globalization;staticclassProgram{staticvoidFillStack(bytevalue){Span<byte>bytes=stackallocbyte[1024*16];bytes.Fill(value);}staticvoidMain(string[]args){if(args.Length!=0){bytefillValue=byte.Parse(args[0],NumberStyles.HexNumber);AppDomain.CurrentDomain.UnhandledException+=(_,_)=>FillStack(fillValue);}thrownewException();}}

When run on Windows, the last thing it does is call RaiseFailFastExceptionhere. The parameters passed to RaiseFailFastException point at the function that raised the unhanded exception. If you debug the process, you can see a call stack after it calls this function. Depending on what argument you pass to the program, you get different call stacks.

If you pass 0 you get:

 ntdll.dll!NtRaiseException�()	Unknown
KernelBase.dll!RaiseFailFastException�()	Unknown
reproNative.exe!S_P_CoreLib_Interop_Kernel32__RaiseFailFastException_0�()	Unknown
>	reproNative.exe!S_P_CoreLib_Interop_Kernel32__RaiseFailFastException() Line 46	Unknown
reproNative.exe!S_P_CoreLib_System_RuntimeExceptionHelpers__FailFast_1() Line 279	Unknown
reproNative.exe!S_P_CoreLib_System_RuntimeExceptionHelpers__RuntimeFailFast() Line 219	Unknown
reproNative.exe!S_P_CoreLib_System_Runtime_EH__UnhandledExceptionFailFastViaClasslib() Line 205	Unknown
reproNative.exe!S_P_CoreLib_System_Runtime_EH__DispatchEx() Line 650	Unknown
reproNative.exe!S_P_CoreLib_System_Runtime_EH__RhThrowEx() Line 572	Unknown
reproNative.exe!RhpThrowEx() Line 190	Unknown
reproNative.exe!repro_Program__Main() Line 24	Unknown
reproNative.exe!repro__Module___MainMethodWrapper()	Unknown
reproNative.exe!repro__Module___StartupCodeMain()	Unknown
reproNative.exe!wmain(int argc, wchar_t * * argv) Line 216	C++
reproNative.exe!invoke_main() Line 91	C++
reproNative.exe!__scrt_common_main_seh() Line 288	C++
reproNative.exe!__scrt_common_main() Line 331	C++
reproNative.exe!wmainCRTStartup(void * __formal) Line 17	C++
kernel32.dll!BaseThreadInitThunk()	Unknown
ntdll.dll!RtlUserThreadStart�()	Unknown

That's less than ideal as it does not directly point at the faulting function.

If you pass ff you get garbage:

 00000000f2d49ff1()	Unknown
000001ed07011578()	Unknown
000001ed07011548()	Unknown
>	reproNative.exe!repro_Program___c__DisplayClass1_0___Main_b__0() Line 22	Unknown

After this PR is merged, the call stack correctly points at the faulting function:

>	reproNative.exe!repro_Program__Main() Line 24	Unknown
reproNative.exe!repro__Module___MainMethodWrapper()	Unknown
reproNative.exe!repro__Module___StartupCodeMain()	Unknown
reproNative.exe!wmain(int argc, wchar_t * * argv) Line 216	C++
reproNative.exe!invoke_main() Line 91	C++
reproNative.exe!__scrt_common_main_seh() Line 288	C++
reproNative.exe!__scrt_common_main() Line 331	C++
reproNative.exe!wmainCRTStartup(void * __formal) Line 17	C++
kernel32.dll!BaseThreadInitThunk()	Unknown
ntdll.dll!RtlUserThreadStart�()	Unknown

TODO before merging:

AMD64: capture CS, SS, and RFLAGS into PAL_LIMITED_CONTEXT when throwing and exception
AMD64: restore CS, SS, and RFLAGS in RhpCopyContextFromExInfo

I won't bother with x86 since it not currently supported by NativeAOT.

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

jkotas · 2023-01-23T04:27:48Z

capture CS, SS, and RFLAGS into PAL_LIMITED_CONTEXT when throwing and exception

I do not think we want to grow PAL_LIMITED_CONTEXT for this. We can capture these registers from current thread by calling GetThreadContext or similar API.

AustinWise · 2023-01-27T18:22:33Z

I did not bother getting the segment registers when running on non-Windows, as the only use of the CONTEXT downstream of RhpCopyContextFromExInfo is on Windows.

VSadov · 2023-01-27T19:01:23Z

I did not bother getting the segment registers when running on non-Windows, as the only use of the CONTEXT downstream of RhpCopyContextFromExInfo is on Windows.

In such case there is no need for a TODO in there. It would be better to instead put a comment justifying that we do not care about these on non-Windows. ~~Maybe zero-init them for determinism.~~

Co-authored-by: Vladimir Sadov <vsadov@microsoft.com>

VSadov

LGTM. Thanks!

AustinWise · 2023-01-31T07:42:04Z

FYI, this problem reproduces with .NET 7.0.2 on Windows 11 22H2. So it should be considered for servicing to the .NET 7 branch.

janvorli

LGTM, thank you!

AustinWise · 2023-02-01T19:06:28Z

Test failure looks like #75244. It the "coreclr Pri0 Runtime Tests Run windows x86 checked" job that failed, so presumably that's unrelated to this NativeAOT change.

jkotas · 2023-02-06T02:53:57Z

FYI, this problem reproduces with .NET 7.0.2 on Windows 11 22H2. So it should be considered for servicing to the .NET 7 branch.

I am not able to reproduce it. What is the program that you were able to reproduce it with?

AustinWise · 2023-02-06T06:03:35Z

FYI, this problem reproduces with .NET 7.0.2 on Windows 11 22H2. So it should be considered for servicing to the .NET 7 branch.
I am not able to reproduce it. What is the program that you were able to reproduce it with?

I made a GitHub repo with the reproduction program and a script that builds and runs:

https://github.com/AustinWise/dotnet-81010

Also included in the readme is the exact versions of software used.

jkotas · 2023-02-08T18:37:42Z

Thanks for great repro!

jkotas · 2023-02-08T18:39:33Z

/backport to release/7.0

github-actions · 2023-02-08T18:39:49Z

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/4127325824

ghost added community-contribution Indicates that the PR has been added by a community member area-NativeAOT-coreclr labels Jan 23, 2023

AustinWise mentioned this pull request Jan 23, 2023
[NativeAOT] Objective-C exception propagation #80334
Merged
10 tasks

[NativeAOT] correctly initalize CONTEXT before failing fast
667caac

AustinWise force-pushed the austin/FailFastContext branch from 68e537e to 667caacCompare January 27, 2023 03:59

AustinWise marked this pull request as ready for review January 27, 2023 18:21

AustinWise requested a review from MichalStrehovsky as a code owner January 27, 2023 18:21

VSadov reviewed Jan 27, 2023
View reviewed changes

Comment threadsrc/coreclr/nativeaot/Runtime/windows/PalRedhawkMinWin.cpp Outdated

AustinWise added 2 commits January 27, 2023 11:24

Switch from using GetThreadContext to RtlCaptureContext.
f29268e

Add a better explination of why the function is unimplmented on Unix.
cebd1c0

VSadov reviewed Jan 27, 2023
View reviewed changes

Comment threadsrc/coreclr/nativeaot/Runtime/PalRedhawk.h Outdated

Update src/coreclr/nativeaot/Runtime/PalRedhawk.h
7d79927
Co-authored-by: Vladimir Sadov <vsadov@microsoft.com>

VSadov approved these changes Jan 27, 2023
View reviewed changes

janvorli reviewed Jan 31, 2023
View reviewed changes

Comment threadsrc/coreclr/nativeaot/Runtime/EHHelpers.cpp Outdated

Respond to feedback: unconditionally set CONTEXT_CONTROL
5f2ba0d

janvorli reviewed Jan 31, 2023
View reviewed changes

Comment threadsrc/coreclr/nativeaot/Runtime/EHHelpers.cpp Outdated

Respond to feedback: consolidate setting of ContextFlags.
81a3d40

janvorli approved these changes Jan 31, 2023
View reviewed changes

On second thought, don't add a second layer of ifdef nesting.
dc8c3ad

build-analysisBot mentioned this pull request Jan 31, 2023
Test failure Loader\\classloader\\DictionaryExpansion\\DictionaryExpansion\\DictionaryExpansion.cmd #75244
Closed

jkotas merged commit 29b6a51 into dotnet:mainFeb 6, 2023

AustinWise deleted the austin/FailFastContext branch February 6, 2023 06:06

github-actionsBot mentioned this pull request Feb 8, 2023
[release/7.0] [NativeAOT] correctly initalize CONTEXT before failing fast #81837
Merged

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

Uh oh!

Conversation

AustinWise commented Jan 23, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Short Explanation

Long Explanation

TODO before merging:

Uh oh!

ghost commented Jan 23, 2023

Short Explanation

Long Explanation

TODO before merging:

Uh oh!

jkotas commented Jan 23, 2023

Uh oh!

AustinWise commented Jan 27, 2023

Uh oh!

VSadov commented Jan 27, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

VSadov left a comment

Choose a reason for hiding this comment

Uh oh!

AustinWise commented Jan 31, 2023

Uh oh!

Uh oh!

Uh oh!

janvorli left a comment

Choose a reason for hiding this comment

Uh oh!

AustinWise commented Feb 1, 2023

Uh oh!

jkotas commented Feb 6, 2023

Uh oh!

AustinWise commented Feb 6, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jkotas commented Feb 8, 2023

Uh oh!

jkotas commented Feb 8, 2023

Uh oh!

github-actionsBot commented Feb 8, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

AustinWise commented Jan 23, 2023•
edited
Loading

VSadov commented Jan 27, 2023•
edited
Loading

AustinWise commented Feb 6, 2023•
edited
Loading