Call mono_unhandled_exception to raise AppDomain.UnhandledException when
managed exceptions are unhandled.
Partial fix for #15252 (for MonoVM, still pending for CoreCLR, which
needs https://github.com/dotnet/runtime/issues/102730 fixed first).
Throw an exception for a condition we don't handle in the dynamic registrar:
calling a base Objective-C constructor (init method) with arguments. Our
current implementation to call the base Objective-C constructor doesn't handle
any arguments, so if the method actually takes any arguments, those will just
be random memory. In other words: a consistent exception is better than a
random invalid memory access.
We're using two different functions to atomically decrement a reference count,
the native `atomic_fetch_sub` and the managed `Interlocked.Decrement`.
Unfortunately the return value is not the same: `atomic_fetch_sub` returns the
original value before the subtraction, while `Interlocked.Decrement` returns
the subtracted value, while our code assumed the functions behaved the same.
This resulted in a memory leak, because we'd incorrectly expect `0` to be
returned from `atomic_fetch_sub` when the reference count reaches zero, and
thus not detect when the descriptor a block should be freed.
The fix is to update the expected return value from `atomic_fetch_sub` to be
`1` instead of `0`.
Fixes https://github.com/xamarin/xamarin-macios/issues/20503.
The stack trace from unhandled exception is now:
Unhandled managed exception: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index') (System.ArgumentOutOfRangeException)
at System.Collections.Generic.List`1[[System.String, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].get_Item(Int32 index)
at CrashiOS.RootViewController.GetItem() in /Users/rolf/test/bugs/StackTraceIssue/CrashiOS/RootViewController.cs:line 19
at CrashiOS.RootViewController.<.ctor>b__1_0(Object _, EventArgs _) in /Users/rolf/test/bugs/StackTraceIssue/CrashiOS/RootViewController.cs:line 12
at UIKit.UIBarButtonItem.Callback.Call(NSObject sender) in xamarin-macios/src/UIKit/UIBarButtonItem.cs:line 33
--- End of stack trace from previous location ---
at ObjCRuntime.Runtime.ThrowException(IntPtr gchandle) in xamarin-macios/src/ObjCRuntime/Runtime.cs:line 2655
at UIKit.UIApplication.UIApplicationMain(Int32 argc, String[] argv, IntPtr principalClassName, IntPtr delegateClassName) in xamarin-macios/src/UIKit/UIApplication.cs:line 64
at UIKit.UIApplication.Main(String[] args, Type principalClass, Type delegateClass) in xamarin-macios/src/UIKit/UIApplication.cs:line 96
at Program.<Main>$(String[] args) in /Users/rolf/test/bugs/StackTraceIssue/CrashiOS/Main.cs:line 26
as opposed to:
Unhandled managed exception: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index') (System.ArgumentOutOfRangeException)
at ObjCRuntime.Runtime.ThrowException(IntPtr gchandle)
at UIKit.UIApplication.UIApplicationMain(Int32 argc, String[] argv, IntPtr principalClassName, IntPtr delegateClassName)
at UIKit.UIApplication.Main(String[] args, Type principalClass, Type delegateClass)
at Program.<Main>$(String[] args) in /Users/rolf/test/bugs/StackTraceIssue/CrashiOS/Main.cs:line 26
Fixes https://github.com/xamarin/xamarin-macios/issues/19417.
Detect recursion when handling unhandled Objective-C exceptions, which can happen if:
* We install a handler for unhandled Objective-C exceptions.
* An unhandled Objective-C exception is caught.
* We convert the unhandled Objective-C exception to a managed exception, and throw that.
* Nobody handles the managed exception either, so we convert it to an Objective-C exception and throw that.
* We re-enter the unhandled Objective-C exception handler, and the cycle continues.
* Eventually the process crashes due to a stack overflow.
Fixes https://github.com/xamarin/xamarin-macios/issues/14796.
Once upon a time we needed to special case a higher min OS version that the
min OS version we supported for certain compiler/linker arguments, because we
used features not supported in the min OS version we supported.
That time has passed; in all cases our min OS version is now higher than the
special-cased min OS versions passed to native compilers/linkers, so we can
just use the actual min OS version we support.
It'll never be called from the generated code from the managed static
registrar, so there's no need to register it as a potential callback from
native code.
This makes the linker able to remove the Runtime.CreateDelegateProxy method
(and a few other methods as well) when using the managed static registrar (and
thus not warn about these methods doing un-trimmable stuff).
Contributes towards #10405.
It'll never be called from the generated code from the managed static
registrar, so there's no need to register it as a potential callback from
native code.
This makes the linker able to remove the Runtime.GetGenericMethodFromToken
method (and a few other methods as well).
Contributes towards #10405.
Calling the direct functions instead of sending messages is slightly faster,
and additionally it may make some static analyzers think we've enabled ARC for
our Objective-C code (which we don't, because we need to manually manage
reference counting).
These direct functions aren't in any public header (they're in a private header),
but they're documented as part of ARC here: https://clang.llvm.org/docs/AutomaticReferenceCounting.html#runtime-support,
and clang emits references to these methods from user code, so it should be safe for us to use them.
Fixes https://github.com/xamarin/xamarin-macios/issues/19413.
Fixed an issue where the C# class name was coming in with `,
AssemblyName` tacked on the end.
Fixed an issue where a class that had an entry in the map didn't have a
`class_ptr` which was causing an NRE.
Fixed a predicate for deciding when to mark the assembly for save.
Note - for an as yet undetermined reason, the linker is not picking up
that I'm marking the assembly for save, which is why the `true` test
cases are commented out.
This fixes issue 16671 https://github.com/xamarin/xamarin-macios/issues/16671
We're going to change the pack names to support multi-targeting, so ahead
of the pack name change I'm changing the existing logic to use a variable
for the pack name in most places (this will make the rename much easier and
simpler).
These changes should have no effect by themselves.
Since NativeAOT generates native libraries and executables that do not
rely on assemblies they were compiled from, all managed assemblies can
be excluded from the application bundle.
This reduces the size of the application bundle by `3,17Mb` (or ~19%
compared to the baseline)
| MAUI ios app | Base | This PR | diff (%) |
|--------------|-----------|-----------|----------|
| SOD (Mb) | 50,13 | 41,93 | -16,3% |
| .ipa (Mb) | 16,59 | 13,43 | -19% |
Fixes: https://github.com/xamarin/xamarin-macios/issues/18472
Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
The timeout can be given:
* By setting the __XAMARIN_DEBUG_CONNECT_TIMEOUT__ environment variable for the app when launching it.
* By passing the XamarinDebugConnectTimeout MSBuild property to 'dotnet run' or 'dotnet build /t:Run'.
* By setting the IOSDebugConnectTimeout MSBuild property at build time.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1778177.
This makes it possible to simplify and remove a good chunk of related code.
Especially for CoreCLR this should be a minor perf improvement, because we'll do fewer transitions between managed and native code.
If we're creating a universal app, and here are satellite assemblies that are not
identical across all RuntimeIdentifiers, those assemblies will be stored in a RuntimeIdentifier-specific
subdirectory during the build.
Unfortunately we didn't know how to find those assemblies at runtime, causing localizations
in universal apps to not work.
This change will:
* Add support for looking in the directory where RID-specific satellite assemblies
are stored.
* Add an assembly resolution event handler to our CoreCLR bridge so that we can
execute our custom lookup code.
* Add an assembly resource lookup test to monotouch-test.
* Add a macOS + Mac Catalyst variation of monotouch-test to xharness that triggers
the bug (a universal test app).
Fixes https://github.com/xamarin/xamarin-macios/issues/16847.
Use function pointers to our managed callbacks instead of delegates for the native->managed bridge. This makes execution faster on AOT (because the AOT compiler can just emit the native function address, no need to go through the expensive marshalling machinery).
This involved a few changes to make the managed callbacks only use blittable types in the function signature:
* Use `sbyte` / `int8_t` instead of `bool`.
* Use pointers instead of `out`/`ref` arguments.
* Use `IntPtr` instead of `string` arguments.
The code rarely shows up in timing profiles before the change, and never after. This means that time-wise this doesn't save all that much, because there wasn't much to gain to begin with (but it's still a gain).
Memory-wise, we're now allocation 0,19 MiB less on startup (17,61 MiB vs 17,42 MiB).
MonoVM in .NET 6+ supports automatic autorelease pools on threadpool threads
just like CoreCLR does, so we can remove our custom mono profiler hooks to
accomplish this.
Fixes https://github.com/xamarin/xamarin-macios/issues/11788.
This will increase app size a little bit: the space for the MVID + 4 bytes for each
assembly, but we'll be able to validate and show a helpful error message if the generated
static registrar code does not match the assembly loaded at runtime.
It's also a step toward per-assembly static registration (ref: #12067).
This avoids one case where we we embed metadata tokens to a different assembly
in the generated static registrar code.
This is required for supporting per-assembly static registration
(https://github.com/xamarin/xamarin-macios/issues/12067).
Rolf Bjarne Kvinge
Haritha Mohan
Steve Hawley
Ivan Povazan
Ivan Povazan