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.

Sign up for GitHub

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

Jump to bottom

P/Invoke custom marshaler sometimes fails type cast #10965

Closed
AArnott opened this issue Aug 24, 2018 · 4 comments
Closed

P/Invoke custom marshaler sometimes fails type cast #10965

AArnott opened this issue Aug 24, 2018 · 4 comments
Labels
area-Interop-coreclr
Milestone
3.0

Comments

@AArnott
Copy link
Contributor

AArnott commented Aug 24, 2018

I'm trying to track down why my upgrade of libgit2sharp to 0.25.2 led to nerdbank.gitversioning to fail (reliably) on a seemingly random set of projects across multiple repos.

In the failure, a type check fails after passing through a very clearly type constraining method. Considering that perhaps it's a matter of assembly double-loading, I checked. The managed debugger reports the assembly is loaded once, and that the AssemblyLoadContext is the same at both points of the callstack leading up to the failure.

This repros only on .NET Core (2.1), and does so on Windows and Linux (I didn't test Mac). This same code works fine within MSBuild running on the .NET Framework.

The repro is super reliable and relatively simple. @rainersigwald also has a great repro.
@AaronRobinsonMSFT
Copy link
Member

@luqunl Could this be addressed by your work with custom marshaling?

cc @jeffschwMSFT

@luqunl luqunl self-assigned this Aug 24, 2018
@luqunl
Copy link
Contributor

luqunl commented Aug 24, 2018

Could this be addressed by your work with custom marshaling?

@AaronRobinsonMSFT , it is similar issue. I will take a look.

@AArnott
Copy link
Contributor Author

AArnott commented Aug 25, 2018

Continuing the investigation in dotnet/Nerdbank.GitVersioning#217 (comment) (since my workaround utterly failed), I found that the p/invoke custom marshaler problem surfaces after the second custom AssemblyLoadContext is created and p/invokes come from that one.

@luqunl luqunl removed their assignment Oct 11, 2018
jkoritzinsky referenced this issue in jkoritzinsky/coreclr Dec 19, 2018
@jkoritzinsky
Create repro for dotnet/coreclr#19654
a7dc093
jkoritzinsky referenced this issue in dotnet/coreclr Jan 14, 2019
@jkoritzinsky
Custom Marshalers in custom-ALC-loaded assemblies results in types lo…
b465094 
…aded from crossing ALCs (#21606)

* Create repro for dotnet/coreclr#19654

* Update ICustomMarshaler.csproj

* Update ICustomMarshaler.csproj

* Clean up repro per feedback.

* Add test case for different assemblies with the same CustomMarshaler name.

* Move EEMarshalingData cache from AppDomain to LoaderAllocator. This fixes the custom-marshaler conflict when using unloadable assembly contexts.

* Internalize the LoaderHeap* parameter.

* Add the pointer to the requesting assembly to the hashtable key.

* Fix linux-musl build break.

* Move Crst out of FEATURE_COMINTEROP block.

* Make sure to copy over the assembly pointer to the key that's actually stored in the hash table.

* Add comment for m_invokingAssembly.

* Move all usages of EEMarshallingData to hang off the correct loader allocator instead of always the global one.

* Change to m_InteropDataCrst since this EEMarshallingData can be used in preemptive GC mode.

* Always init m_InteropDataCrst (since it's used by EEMarshallingData as well as COM).

* PR Feedback.

* Remove extraneous inlines.
@jkoritzinsky
Copy link
Member

Fixed by dotnet/coreclr#21606

@msftgits msftgits transferred this issue from dotnet/coreclr Jan 31, 2020
@msftgits msftgits added this to the 3.0 milestone Jan 31, 2020
@CoffeeFlux CoffeeFlux mentioned this issue Apr 5, 2020
Closed
@ghost ghost locked as resolved and limited conversation to collaborators Dec 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area-Interop-coreclr
Projects
None yet
Milestone
3.0
Development

No branches or pull requests
5 participants
@AArnott @jkoritzinsky @msftgits @luqunl @AaronRobinsonMSFT