Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assembly::Load crashes C++/CLI app in try block with 9.0.0-rc.2.24473.5 #109242

Closed
samcook-mathworks opened this issue Oct 25, 2024 · 3 comments · Fixed by #109524
Closed

Assembly::Load crashes C++/CLI app in try block with 9.0.0-rc.2.24473.5 #109242

samcook-mathworks opened this issue Oct 25, 2024 · 3 comments · Fixed by #109524
Assignees
Labels
area-ExceptionHandling-coreclr in-pr There is an active PR which will close this issue when it is merged
Milestone

Comments

@samcook-mathworks
Copy link

samcook-mathworks commented Oct 25, 2024

Description

It's bizarre to say the least. Take this C++/CLI code:

#include "pch.h"

using namespace System;

extern "C" __declspec(dllexport) void __stdcall foobar() {
    Console::WriteLine("Hiya!");
    try {
        Console::WriteLine("Inside try");
        System::String^ s = "System";
        System::Reflection::Assembly^ a = System::Reflection::Assembly::Load(s);
        Console::WriteLine(a->FullName);
        Console::WriteLine(a->Location);
    } catch (...) {
        Console::WriteLine("Exception");
    }
    Console::WriteLine(System::Runtime::InteropServices::RuntimeInformation::FrameworkDescription);
}

Which I invoke from a plain C++ app:

#include <windows.h>
#include <iostream>
typedef void (__stdcall *f_funci)();
int main()
{
    std::cout << "From C++" << std::endl;
    HINSTANCE hGetProcIDDLL = LoadLibraryA("C:\\Users\\samcook\\source\\repos\\CppCliApp\\x64\\Debug\\CppCliApp.dll");
    f_funci funci = (f_funci)GetProcAddress(hGetProcIDDLL, "foobar");
    funci();
}

Every time this crashes the application. If I pass nullptr instead of "System" then the crash does not occur.

Reproduction Steps

Here is a zip file. You'll have the change the line in CppApp.cpp to point to the correct DLL.

CppCliApp.zip

> cd C:\Users\<user>\source\repos\CppCliApp
> msbuild -restore
> msbuild
> .\x64\Debug\CppApp.exe

The application will crash.

Expected behavior

No crash.

Actual behavior

Crash with stack trace:

coreclr.dll!__report_gsfailure(unsigned __int64 stack_cookie) Line 220
	at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\gs\gs_report.c(220)
[Inline Frame] coreclr.dll!DoJITFailFast() Line 3298
	at D:\a\_work\1\s\src\coreclr\vm\jithelpers.cpp(3298)
coreclr.dll!CrawlFrame::CheckGSCookies() Line 363
	at D:\a\_work\1\s\src\coreclr\vm\stackwalk.cpp(363)
[Inline Frame] coreclr.dll!StackFrameIterator::PreProcessingForManagedFrames() Line 3193
	at D:\a\_work\1\s\src\coreclr\vm\stackwalk.cpp(3193)
[Inline Frame] coreclr.dll!StackFrameIterator::ProcessCurrentFrame() Line 3029
	at D:\a\_work\1\s\src\coreclr\vm\stackwalk.cpp(3029)
coreclr.dll!StackFrameIterator::NextRaw() Line 2812
	at D:\a\_work\1\s\src\coreclr\vm\stackwalk.cpp(2812)
[Inline Frame] coreclr.dll!StackFrameIterator::Next() Line 1623
	at D:\a\_work\1\s\src\coreclr\vm\stackwalk.cpp(1623)
coreclr.dll!Thread::StackWalkFramesEx(REGDISPLAY * pRD, StackWalkAction(*)(CrawlFrame *, void *) pCallback, void * pData, unsigned int flags, Frame * pStartFrame) Line 917
	at D:\a\_work\1\s\src\coreclr\vm\stackwalk.cpp(917)
coreclr.dll!Thread::StackWalkFrames(StackWalkAction(*)(CrawlFrame *, void *) pCallback, void * pData, unsigned int flags, Frame * pStartFrame) Line 992
	at D:\a\_work\1\s\src\coreclr\vm\stackwalk.cpp(992)
coreclr.dll!SystemDomain::GetCallersModule(StackCrawlMark * stackMark) Line 1495
	at D:\a\_work\1\s\src\coreclr\vm\appdomain.cpp(1495)
[Inline Frame] coreclr.dll!SystemDomain::GetCallersAssembly(StackCrawlMark *) Line 1511
	at D:\a\_work\1\s\src\coreclr\vm\appdomain.cpp(1511)
coreclr.dll!AssemblyNative_InternalLoad(NativeAssemblyNameParts * pAssemblyNameParts, QCall::ObjectHandleOnStack requestingAssembly, QCall::StackCrawlMarkHandle stackMark, int fThrowOnFileNotFound, QCall::ObjectHandleOnStack assemblyLoadContext, QCall::ObjectHandleOnStack retAssembly) Line 64
	at D:\a\_work\1\s\src\coreclr\vm\assemblynative.cpp(64)
System.Private.CoreLib.dll!00007ffcd06c41c3()
System.Private.CoreLib.dll!00007ffcd06b787c()

With locals:

+		cookie	0x0000002037bf6be0 {4359, 18725272692747}	volatile unsigned __int64[2]
		stack_cookie	0	unsigned __int64

Regression?

No response

Known Workarounds

No response

Configuration

Runtime: 9.0.0-rc.2.24473.5
SDK: 9.0.100-rc.2.24474.11
MSBuild: MSBuild version 17.11.9+a69bbaaf5 for .NET Framework 17.11.9.46202

Other information

No response

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Oct 25, 2024
@AaronRobinsonMSFT
Copy link
Member

@janvorli Anything above ring a bell?

@jkotas
Copy link
Member

jkotas commented Nov 4, 2024

This is regression introduced by #99137. The crash is triggered by calling Assembly.Load in a method with stackalloc on Windows x64.

Small C# repro:

using System.Reflection;

m();

static void m()
{
    unsafe
    {
        void* p = stackalloc byte[Random.Shared.Next(100)];
        Console.WriteLine((IntPtr)p);
    }

    Assembly.Load("System.Runtime");
}

@jkotas jkotas self-assigned this Nov 4, 2024
@AaronRobinsonMSFT AaronRobinsonMSFT removed the untriaged New issue has not been triaged by the area owner label Nov 4, 2024
@AaronRobinsonMSFT AaronRobinsonMSFT added this to the 10.0.0 milestone Nov 4, 2024
@dotnet-policy-service dotnet-policy-service bot added the in-pr There is an active PR which will close this issue when it is merged label Nov 4, 2024
jkotas added a commit to jkotas/runtime that referenced this issue Nov 4, 2024
LightUnwind does not track sufficient context to compute GS cookie address

Fixes dotnet#109242
jkotas added a commit to jkotas/runtime that referenced this issue Nov 4, 2024
LightUnwind does not track sufficient context to compute GS cookie address

Fixes dotnet#109242
@jkotas jkotas closed this as completed in da78cf7 Nov 5, 2024
github-actions bot pushed a commit that referenced this issue Nov 5, 2024
LightUnwind does not track sufficient context to compute GS cookie address

Fixes #109242
@jkotas
Copy link
Member

jkotas commented Nov 5, 2024

Thank you for reporting this issue! We expect that the fix will be included in January 2025 .NET 9 servicing update.

If you need to work-around the issue in the meantime, it can be done by factoring out the Assembly.Load call into a separate non-inlineable method:

using namespace System::Runtime::CompilerServices;

[MethodImpl(MethodImplOptions::NoInlining)]
__declspec(noinline)
static System::Reflection::Assembly^ AssemblyLoadWorkaround(System::String^ s)
{
    return System::Reflection::Assembly::Load(s);
}
...
        System::String^ s = "System";
        System::Reflection::Assembly^ a = AssemblyLoadWorkaround(s);
        Console::WriteLine(a->FullName);
...

@github-actions github-actions bot locked and limited conversation to collaborators Dec 5, 2024
mikelle-rogers pushed a commit to mikelle-rogers/runtime that referenced this issue Dec 10, 2024
LightUnwind does not track sufficient context to compute GS cookie address

Fixes dotnet#109242
jkotas added a commit that referenced this issue Jan 9, 2025
LightUnwind does not track sufficient context to compute GS cookie address

Fixes #109242

Co-authored-by: Jan Kotas <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-ExceptionHandling-coreclr in-pr There is an active PR which will close this issue when it is merged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants