| Age | Commit message (Collapse) | Author |
|---|
|
|
|
According to Apple's headers, it's not used anymore, and ignored.
However, with Xcode 13.3, it seems Apple has re-used this value for something
else, and it's causing warnings in the linker:
> ld: warning: '[...]/arm64/Xamarin.iOS.dll.o' was built with class_ro_t pointer signing enabled, but previous .o files were not
Fixes https://github.com/mono/mono/issues/21450.
Ref: https://opensource.apple.com/source/objc4/objc4-818.2/runtime/objc-abi.h.auto.html
|
|
Free the method builder after compiling the wrapper.
This is already fixed on mono/mono `main` as part of the refactoring in
https://github.com/mono/mono/pull/19768 (And that change was also propagated to
dotnet/runtime)
|
|
(cherry picked from commit 71ad7a0460627eb899bc54cfe33a2584419f75f8)
|
|
(#21435)
* [Android] Workaround for invalid return value from clock_nanosleep (#21433)
Fixes https://github.com/xamarin/xamarin-android/issues/6600
Backported from https://github.com/dotnet/runtime/pull/64679 and https://github.com/dotnet/runtime/pull/65373
(cherry picked from commit 36daf033a620d800f6e65f4544ea55a3ecef7af0)
* Fix Windows build
Co-authored-by: Simon Rozsival <simon@rozsival.com>
|
|
(cherry picked from commit 1faa76848158e160207fa65a18fc0ff462799c4b)
|
|
One of the changes in macios revealed a bug in which @new can be null
resulting in a NRE like the one that follows:
System.NullReferenceException: Object reference not set to an instance of an object
2022-01-26T09:23:11.9538790Z at Mono.ApiTools.MarkdownFormatter.DiffModification (System.Text.StringBuilder output, System.String old, System.String new, System.Boolean breaking) [0x00013] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/MarkdownFormatter.cs:181
2022-01-26T09:23:11.9543530Z at Mono.ApiTools.ApiChange.AppendModified (System.String old, System.String new, System.Boolean breaking) [0x00000] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ApiChange.cs:49
2022-01-26T09:23:11.9547700Z at Mono.ApiTools.FieldComparer.Equals (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target, Mono.ApiTools.ApiChanges changes) [0x0008c] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/FieldComparer.cs:123
2022-01-26T09:23:11.9551430Z at Mono.ApiTools.MemberComparer.Compare (System.Collections.Generic.IEnumerable`1[T] source, System.Collections.Generic.IEnumerable`1[T] target) [0x00053] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/MemberComparer.cs:111
2022-01-26T09:23:11.9554840Z at Mono.ApiTools.MemberComparer.Compare (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target) [0x00064] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/MemberComparer.cs:66
2022-01-26T09:23:11.9558230Z at Mono.ApiTools.ClassComparer.Modified (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target, Mono.ApiTools.ApiChanges diff) [0x00172] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ClassComparer.cs:238
2022-01-26T09:23:11.9562840Z at Mono.ApiTools.Comparer.Compare (System.Collections.Generic.IEnumerable`1[T] source, System.Collections.Generic.IEnumerable`1[T] target) [0x00084] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/Comparer.cs:94
2022-01-26T09:23:11.9566810Z at Mono.ApiTools.ClassComparer.Compare (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target) [0x0002c] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ClassComparer.cs:68
2022-01-26T09:23:11.9570610Z at Mono.ApiTools.NamespaceComparer.Modified (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target, Mono.ApiTools.ApiChanges differences) [0x00017] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/NamespaceComparer.cs:79
2022-01-26T09:23:11.9574480Z at Mono.ApiTools.Comparer.Compare (System.Collections.Generic.IEnumerable`1[T] source, System.Collections.Generic.IEnumerable`1[T] target) [0x00084] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/Comparer.cs:94
2022-01-26T09:23:11.9578000Z at Mono.ApiTools.NamespaceComparer.Compare (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target) [0x0002c] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/NamespaceComparer.cs:51
2022-01-26T09:23:11.9581650Z at Mono.ApiTools.AssemblyComparer.Modified (System.Xml.Linq.XElement source, System.Xml.Linq.XElement target, Mono.ApiTools.ApiChanges diff) [0x00055] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/AssemblyComparer.cs:89
2022-01-26T09:23:11.9586220Z at Mono.ApiTools.Comparer.Compare (System.Collections.Generic.IEnumerable`1[T] source, System.Collections.Generic.IEnumerable`1[T] target) [0x00084] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/Comparer.cs:94
2022-01-26T09:23:11.9589520Z at Mono.ApiTools.AssemblyComparer.Compare () [0x00000] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/AssemblyComparer.cs:63
2022-01-26T09:23:11.9592880Z at Mono.ApiTools.ApiDiffFormatted.Generate (Mono.ApiTools.AssemblyComparer ac, System.IO.TextWriter outStream, Mono.ApiTools.State state) [0x00013] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ApiDiff.cs:222
2022-01-26T09:23:11.9596490Z at Mono.ApiTools.ApiDiffFormatted.Generate (System.String firstInfo, System.String secondInfo, System.IO.TextWriter outStream, Mono.ApiTools.State state) [0x00008] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ApiDiff.cs:208
2022-01-26T09:23:11.9600250Z at Mono.ApiTools.ApiDiffFormatted.Generate (System.String firstInfo, System.String secondInfo, System.IO.TextWriter outStream, Mono.ApiTools.ApiDiffFormattedConfig config) [0x00007] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ApiDiff.cs:202
2022-01-26T09:23:11.9603590Z at Mono.ApiTools.Program.Main (System.String[] args) [0x002f9] in /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mcs/tools/mono-api-html/ApiDiff.cs:159
The change that exposed the bug is: https://github.com/xamarin/xamarin-macios/commit/d78aa6712b15659b0fed259952364c060ffedcea
The above exception is avoided by ensuring that nor old or @new are
null.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
|
|
When processing the overrides from interface default methods we should
check if the interface class is a generic type definition first and
inflate with the interface class context.
Fixes dotnet/runtime#61244
Co-authored-by: bholmes <bholmes@users.noreply.github.com>
|
|
Co-authored-by: Marek Habersack <grendel@twistedcode.net>
|
|
When the field is byref but the value being passes in is not, throw an
ArgumentException. Without this change the call to
mono_object_handle_pin_unbox will assert and kill the process.
This can occur when de-serializing an object and the field types have
changed.
Co-authored-by: bholmes <bholmes@users.noreply.github.com>
|
|
disable Ping tests
|
|
The mono_field_static_get_value method uses a handle, but did not set up
enter/exit macros properly, so this handle was leaked.
Some code in Unity calls this embedding API method pretty often, which
can lead to the mark stack overflowing in the GC code.
Co-authored-by: Josh Peterson <joshuap@unity3d.com>
|
|
These structures are valuetypes, but their mint_type is a primitive. This means that a LDFLD applied on the type would have attempted to do a pointer dereference, because it saw that the current top of stack is not STACK_TYPE_VT. This was fixed in the past by passing the managed pointer to the valuetype rather than the valuetype itself, against the normal call convention, which lead to inconsistencies in the code.
This commit removes that hack and fixes the problem by ignoring LDFLD applied to nint/nfloat valuetypes in the first place.
|
|
job_major_mod_union_preclean (#21391)
fixes #21369
Related to https://github.com/xamarin/xamarin-android/issues/6546
job_major_mod_union_preclean can race with the tarjan bridge
implementation that changes the vtable pointer by settings the three
lower bits. this results in invalid loading of the vtable
(shifted by 7 bytes) which in turn give a wrong desc to the scan
functions
This change is released under the MIT license.
Co-authored-by: Thomas Mijieux <thomas.mijieux@hotmail.fr>
|
|
(#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>
|
|
resolution in monterey (#21351)
Backport of #21326 to 2020-02
Co-authored-by: Jose Medrano <josmed@microsoft.com>
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
|
|
duplicate symbol errors during static linking. (#21309)
Fixes https://github.com/mono/mono/issues/20417.
Co-authored-by: Zoltan Varga <vargaz@gmail.com>
|
|
We don't use these feeds in mono/mono.
|
|
Xamarin.MacCatalyst.dll as well. (#21261)
Ref: https://github.com/xamarin/xamarin-macios/pull/13092
|
|
(#21126)" (#21240)
This reverts commit 63035635944865e83afee8efd6c346af1c077d58.
|
|
|
|
GitHub is removing support for unencrypted git soon: https://github.blog/2021-09-01-improving-git-protocol-security-github/
(cherry picked from commit d4a369b3e651ca92e27ae711c37177e1f42fa300)
|
|
.NET 6 RC 2 adds an MSBuild check to see that the VisualStudioVersion
property is below 17.0 and reports a not supported warning if this is
the case. Updating the VisualStudioVersion to 17.0 used in Visual
Studio for Mac 17.0 to fix this warning breaks F# SDK projects and
classic F# projects since Mono's MSBuild tries to load F# targets
files from a directory which does not exist:
xbuild/Microsoft/VisualStudio/v17.0/FSharp
Adding a v17.0 directory to Mono allows Visual Studio for Mac 17.0
to define VisualStudioVersion to be 17.0 and restore and build F#
projects.
|
|
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>
|
|
Don't unbox a valuetype `this` if the generic method is a DIM
Fixes https://github.com/dotnet/runtime/issues/58394
Fixes https://github.com/mono/mono/issues/21206
Co-authored-by: lambdageek <lambdageek@users.noreply.github.com>
|
|
* Ignore EINVAL errors on ioctl TIOCMGET/TIOCMSET so (#20219)
pseudo-ttys are usable. (#20218)
* Fix pseudo-ttys for kernel versions >= 5.13 (#21203)
Co-authored-by: csanchezdll <csanchezdll@gmail.com>
|
|
* [mono] Fix race during mono_image_storage_open (#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 (#19434)
Fixes abort when PTR-FNPTR field signature is encountered.
Fixes https://github.com/mono/mono/issues/12098
Fixes https://github.com/mono/mono/issues/17113
Fixes https://github.com/mono/mono/issues/19433
* Ensure generic parameter constraint type is included when building image (#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>
|
|
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](https://github.com/xamarin/xamarin-android/issues/4602#issuecomment-618201419).
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).
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>
|
|
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>
|
|
Add a new mono_pmip_u that doesn't do the transition.
The intent is that Mono developers in the debugger can call still call
mono_pmip_u if the thread state machine is in a broken state.
|
|
Co-authored-by: Fan Yang <52458914+fanyang-mono@users.noreply.github.com>
|
|
Related to #21009.
There are two scenarios:
1. When someone force quits Mono (or just runs `kill -TERM <pid>`), the process can receive the signal on any thread,
2. or - if a thread in the process crashes, but the thread is not attached to the runtime, Mono's signal handlers still run.
The crash reporter assumes that the crashing thread is either attached to the runtime, or at least `mono_thread_info_current` or the JIT TLS data are set for the thread. If the thread is truly foreign and it never interacted with Mono, and it crashes, both of those assumptions are false, but Mono's crash reporter signal handlers still run.
The solution from this PR is: if crash reporting is enabled, start a dedicated thread at process startup that is a "crash report leader" - when a crash happens, the crashing thread (the crash originator) wakes the leader, and the leader collects the crash report. The crash originator does not do any work that requires being attached to the runtime or to the JIT such as iterating over thread IDs or stack walking.
---
* Add a standalone test of crash on a foreign thread
* Sketch out crash leader implementation
At process startup, start a separate thread that is attached to the runtime and can collect crash reports. Crashing threads will wake it and wait for it to collect the crash reports
* Start moving responsibilities to the crash leader
* Watch for nil jit_tls data if crash is on a foreign thread
* Start adding a state machine for the crash leader
We need to coordinate the originator and the leader in a few places.
The leader needs to pause to after collecting the thread ids before suspending the non-originator threads, and again while the originator is dumping its own stack.
The originator needs to wait for the leader to collect the thread IDs and to tell it its assigned slot. Then it tells the leader to suspend the others, dumps its own memory, then tell the leader to dump the whole crash report and wait for it to reply when it's done.
* Move remaining summarizer work to the summarizer leader thread
* change some debug printfs
* Successfully summarize a foreign thread crash
* Add test to merp-crash-test.cs
* delete standalone test
* if the crash leader is the originator, collect the report synchronously
either because the crash leader crashed, or because the process got a SIGTERM and it arrived on the crash leader thread
* fixup comments
* turn off crash leader printf debugging
* Don't create leader thread if crash reporting is disabled
* Fix test on win32
* Update mono/tests/libtest.c
* fixup logging and comments around managed stack collection
* Disable the merp dlopen crasher
* Remove crash leader state machine
It's straightline code with two early exits. State machine is overkill
* remove remnants of leader state machine
|
|
|
|
Accessing the storage account fails now when using plain http.
|
|
For some reason it recently fails with weird race conditions, let's see if that helps.
|
|
|
|
Related to https://github.com/mono/mono/issues/21040 and
https://github.com/dotnet/runtime/issues/48663
On MacOS Big Sur open() is much more likely to throw EINTR - and moreover if
the thread receives a signal while doing an open() even if the signal handler
is marked with SA_RESTART, the open call appears not to restart and to fail
anyway.
So wrap all the calls to open() in retry loops.
|
|
* [System.Native] Handle ReadDir EINTR
Handle EINTR for opendir/readdir/closedir.
Because of how thread aborts work, we must loop in managed.
A thread abort will break syscalls and return EINTR, but mono will not raise a
ThreadAbortException until a pinvoke returns.
(Despite the documentation, opendir/readdir/closedir sometimes return EINTR on
macOS Big Sur.)
Related to https://github.com/mono/mono/issues/20799
* bump corefx
* [System] on unix, include Interop.ReadDir.Mono.cs
on mac it's in corlib, on unix and android it's in System, for some reason
* Add newline
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
|
|
Bump to mono/corefx@38e9a9317c2cf78611506c491cf27c5fddf9828c
Diff: https://github.com/mono/corefx/compare/7c24bb0756fd39fbf09b8777f25c15d21d78eb46...38e9a9317c2cf78611506c491cf27c5fddf9828c
Primarily CredScan fixes.
Bump before we do a backport to 2020-02 of https://github.com/mono/mono/pull/21016 which will need one more corefx bump
|
|
Transitioning from ArgVtypeByRefOnStack to ArgVtypeByRef requires no marshalling. The reference ends up being saved on stack the same way and the stack slot just needs to be copied (in mono_arm_start_gsharedvt_call).
|
|
myget.org feeds were disabled recently.
(cherry picked from commit dbc5d758afdd3abdfedccb10d21b0fc3015f3312)
|
|
* [mini] Add missing opcodes for r4 to native int conversions
* [interp] Add handling for conv.i from r4
|
|
(cherry picked from commit 9f550fa85caa4141ef422ec4f1a554b5ce7d08c3)
|
|
Bump to MSBuild vs16.9, Roslyn 3.9.0 and NuGet 5.9.0
Backport of https://github.com/mono/mono/pull/20979
|
|
See https://github.com/mono/mono/issues/20982
(cherry picked from commit fbdbe8395949668d2584dcbc0072029da9ac7a86)
|
|
https://github.com/mono/mono/issues/20948
|
|
|
|
* [tests] Add BStr and VARIANT in structs interop tests
* [marshal] Fix reverse P/Invoke marshaling VARIANT fields
Partial revert of https://github.com/mono/mono/pull/8732
If a managed struct is declared as
public struct StructWithVariant
{
[MarshalAs (UnmanagedType.Struct)]
public object data;
};
Then the `data` field should be marshalled as a VARIANT.
The fix checks that the field's type is `object` and uses VARIANT for
marshaling, otherwise it continues as in mono/mono#8732 and uses
MONO_MARSHAL_CONV_OBJECT_STRUCT
* [marshal] Marshal BSTR from reverse pinvokes
|
|
offsets-tool can run before mono-dtrace.h is generated which leads to a compiler error about the file missing.
|
|
Adds Apple silicon support from https://github.com/mono/mono/pull/20597 to 2020-02
Co-authored-by: Zoltan Varga <vargaz@gmail.com>
Co-authored-by: Ilia <ki.stfu@gmail.com>
Co-authored-by: Aleksey Kliger (λgeek) <alklig@microsoft.com>
Co-authored-by: mathieubourgeois <mathieu.bourgeois@gameloft.com>
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
|
