- Apr 20, 2022
-
-
github-actions[bot] authored
* Use upstream zlib 1.2.12 * [zlib] Cherrypick upstream crc32 fix Cherrypick crc32 fix to restore pre-1.2.12 behavior https://github.com/madler/zlib/commit/ec3df00224d4b396e2ac6586ab5d25f673caa4c2 > The previous releases of zlib were not sensitive to incorrect CRC > inputs with bits set above the low 32. This commit restores that > behavior, so that applications with such bugs will continue to > operate as before. Co-authored-by: Aleksey Kliger <alklig@microsoft.com>
-
- Apr 19, 2022
-
-
github-actions[bot] authored
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
-
- Apr 05, 2022
-
-
Aleksey Kliger (λgeek) authored
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)
-
- Mar 22, 2022
-
-
Alexander Köplinger authored
(cherry picked from commit 71ad7a04)
-
- Feb 17, 2022
-
-
Alexander Köplinger authored
* [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 36daf033) * Fix Windows build Co-authored-by: Simon Rozsival <simon@rozsival.com>
-
Alexander Köplinger authored
(cherry picked from commit 1faa7684)
-
- Feb 14, 2022
-
-
github-actions[bot] authored
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>
-
- Feb 07, 2022
-
-
Aleksey Kliger (λgeek) authored
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>
-
github-actions[bot] authored
Co-authored-by: Marek Habersack <grendel@twistedcode.net>
-
- Feb 02, 2022
-
-
github-actions[bot] authored
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>
-
Alexander Köplinger authored
-
- Jan 24, 2022
-
-
github-actions[bot] authored
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>
-
- Jan 13, 2022
-
-
Vlad Brezae authored
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.
-
- Jan 04, 2022
-
-
github-actions[bot] authored
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>
-
- Dec 13, 2021
-
-
github-actions[bot] authored
* [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>
-
- Nov 30, 2021
-
-
github-actions[bot] authored
Backport of #21326 to 2020-02 Co-authored-by: Jose Medrano <josmed@microsoft.com> Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
-
- Nov 19, 2021
-
-
github-actions[bot] authored
[aot] Prepend the assembly name to the names of gsharedvt wrappers to avoid duplicate symbol errors during static linking. (#21309) Fixes https://github.com/mono/mono/issues/20417 . Co-authored-by: Zoltan Varga <vargaz@gmail.com>
-
- Nov 10, 2021
-
-
Alexander Köplinger authored
We don't use these feeds in mono/mono.
-
- Nov 03, 2021
-
-
Rolf Bjarne Kvinge authored
Allow nfloat to be in the ObjCRuntime namespace, and make it work for Xamarin.MacCatalyst.dll as well. (#21261) Ref: https://github.com/xamarin/xamarin-macios/pull/13092
-
- Oct 07, 2021
-
-
Aleksey Kliger (λgeek) authored
This reverts commit 63035635.
-
- Sep 30, 2021
-
-
Vlad Brezae authored
-
- Sep 28, 2021
-
-
Alexander Köplinger authored
GitHub is removing support for unencrypted git soon: https://github.blog/2021-09-01-improving-git-protocol-security-github/ (cherry picked from commit d4a369b3)
-
- Sep 27, 2021
-
-
Matt Ward authored
.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.
-
- Sep 03, 2021
-
-
github-actions[bot] authored
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>
-
github-actions[bot] authored
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>
-
- Aug 30, 2021
-
-
Aleksey Kliger (λgeek) authored
* 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>
-
- Aug 19, 2021
-
-
Marius Ungureanu authored
* [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>
-
github-actions[bot] authored
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). ![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>
-
github-actions[bot] authored
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>
-
- Aug 13, 2021
-
-
Aleksey Kliger (λgeek) authored
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.
-
- Jun 25, 2021
-
-
Marius Ungureanu authored
Co-authored-by: Fan Yang <52458914+fanyang-mono@users.noreply.github.com>
-
- Jun 24, 2021
-
-
Aleksey Kliger (λgeek) authored
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
-
- May 27, 2021
-
-
Matt Ward authored
-
- May 10, 2021
-
-
Alexander Köplinger authored
Accessing the storage account fails now when using plain http.
-
Alexander Köplinger authored
For some reason it recently fails with weird race conditions, let's see if that helps.
-
Ryan Lucia authored
-
- Apr 30, 2021
-
-
Aleksey Kliger (λgeek) authored
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.
-
- Apr 29, 2021
-
-
Aleksey Kliger (λgeek) authored
* [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>
-
- Apr 19, 2021
-
-
Aleksey Kliger (λgeek) authored
Bump to mono/corefx@38e9a931 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
-
- Apr 13, 2021
-
-
Vlad Brezae authored
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).
-