[2020-02] [cominterop] Add coop handle enter/return on native CCW met…

…hods (mono#21366)

* [tests] Add CCW GetIUnknownForObject leak test

* [cominterop] Add coop handle enter/return on native CCW methods

The CCW methods for IUnknown (and in principle IDispatch - except they all have
trivial bodies) are native C code in the runtime that may allocate coop
handles.  Add a coop handle frame around the entire call in order to make sure
they're cleaned up and don't retain a reference.

This helps fix managed object leaks with code like:

```
   var o  = new SomeClass();
   var pUnk = Marshal.GetIUnknownForObject(o);
   int c = Marshal.Release(pUnk);
   o = null;
```

Which retains a reference to the `SomeClass` instance that won't be collected
until the thread dies, despite cleaning up the IUnknown refcount. The underling
ccw addref/release methods leak coop handles on the thread.

This is not an issue when the CCW calls some managed method because there are
no coop handles there until some icall (at which point it will set up the
coop handle stack properly).

Co-authored-by: Aleksey Kliger <alklig@microsoft.com>

[2020-02] Adds full path to libcairo for correct assembly directory r…

…esolution in monterey (mono#21351)

Backport of mono#21326 to 2020-02

Co-authored-by: Jose Medrano <josmed@microsoft.com>
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>

[aot] Prepend the assembly name to the names of gsharedvt wrappers to…

… avoid duplicate symbol errors during static linking. (mono#21309)

Fixes mono#20417.

Co-authored-by: Zoltan Varga <vargaz@gmail.com>

Revert "[2020-02] Start a dedicated thread for MERP crash reporting (m…

…ono#21126)" (mono#21240)

This reverts commit 6303563.

Stop using git protocol for submodules

GitHub is removing support for unencrypted git soon: https://github.blog/2021-09-01-improving-git-protocol-security-github/

(cherry picked from commit d4a369b)

Ignore inherit param for ParameterInfo.GetCustomAttributes (mono#21201)

It is documented that the inherit flag is ignored.
Attribute.GetCustomAttributes is to be used to search
inheritance chain.

This change is only for the Mono classlib implementation.
CoreCLR already has this behavior.

Co-authored-by: Bill Holmes <bill.holmes@unity3d.com>

[2020-02][linux] Some pseudo-tty fixes (mono#21205)

* Ignore EINVAL errors on ioctl TIOCMGET/TIOCMSET so (mono#20219)

pseudo-ttys are usable. (mono#20218)

* Fix pseudo-ttys for kernel versions >= 5.13 (mono#21203)

Co-authored-by: csanchezdll <csanchezdll@gmail.com>

2020 02 backport metadata fixes (mono#21190)

* [mono] Fix race during mono_image_storage_open (mono#21142)

* The mono_refcount_inc call in mono_image_storage_trypublish or
  mono_image_storage_tryaddref may abort when racing against a
  mono_image_storage_dtor that already decremented the refcount.

This race triggered in some cases when building aspnetcore using a Mono-based dotnet host SDK.   The problem is that `mono_image_storage_close` runs outside the `mono_images_storage_lock` (and this may be unavoidable due to lock ordering concerns).  Therefore, we can have a refcount that was already decremented to zero, but before `mono_image_storage_dtor` finishes removing the object from `images_storage_hash`, a parallel `mono_image_storage_trypublish` may have retrieved it from there.  In that case, the `mono_refcount_inc` call will abort.

Fixed by detecting that case via `mono_refcount_tryinc` instead, and simply treating the object as if it had already been removed.  It will in time actually get removed, either by the parallel `mono_image_storage_dtor`, or else by the `g_hash_table_insert` in `mono_image_storage_trypublish` (which will safely replace it with the new object, and `mono_image_storage_dtor` will then detect that and skip removal).

Co-authored-by: uweigand <uweigand@users.noreply.github.com>

* [metadata] Handle MONO_TYPE_FNPTR case in collect_type_images (mono#19434)

Fixes abort when PTR-FNPTR field signature is encountered.

Fixes mono#12098
Fixes mono#17113
Fixes mono#19433

* Ensure generic parameter constraint type is included when building image (mono#19395)

sets.

Making associated change to type_in_image to also check the constrained type for a match. Re-adding asserts now they they no longer trigger.

fixup, accidentally used old function

adjusting coding convention to K&R

Co-authored-by: monojenkins <jo.shields+jenkins@xamarin.com>
Co-authored-by: uweigand <uweigand@users.noreply.github.com>
Co-authored-by: Jeff Smith <whydoubt@gmail.com>
Co-authored-by: Alex Thibodeau <alexthibodeau@unity3d.com>

[Mono.Profiler.Aot] Write true string wire length (mono#21196)

In some cases, it seems like Mono.Profiler.Aot `ProfileWriter` can produce custom profiles that are unable to be read by `ProfileReader` (or `aot-compiler.c`). There are a few reports [here](dotnet/android#4602 (comment)).

I investigated and found a cause may be the writing of incorrect string length markers in situations where `String.Length` is less than the encoded byte length. In that kind of case, the reader falls out of sync with the record structure and quickly fails. [Here is an example dependency](https://www.fuget.org/packages/AuroraControls.Core/1.2020.520.2/lib/netstandard2.0/Aurora.dll) with members that can produce the issue (I guess the odd characters are caused by obfuscation).

![image](https://user-images.githubusercontent.com/7392704/129899400-086a6e8a-373c-4601-837a-5255e7f93d82.png)

I don't think the change requires a profile format version bump, as the format itself is unchanged. 

Co-authored-by: Ryan Davis <ryandavis.au@gmail.com>

Adding null check to avoid abort when invalid IL is encountered (mono…

…#21195)

When a callvirt instruction is encountered on a static method, there is
a hard abort/crash. This commit avoids the problem.

Co-authored-by: Bill Holmes <bill.holmes@unity3d.com>