`calloc` can return `null` and we're writing to the memory location
which would crash the process.
An `OutOfMemoryException` is the correct way to handle this (even if
will likely crash the process anyway).
* [Foundation] Add an NSArray.FromNSObjects overload that can take an array of INativeObjects.
* [runtime] Use mono_array_setref instead of mono_array_set.
Otherwise the GC won't know about the assignment, and the assigned value can
be freed if it's no longer referenced anywhere else.
* Add optional mono_dangerous_add_raw_internal_call to exports.t4
* Use mono_dangerous_add_raw_internal_call on watchOS for icall registration
Internal calls added with mono_dangerous_add_raw_internal_call run in GC Unsafe
mode under cooperative and hybrid suspend, whereas internal calls added with
mono_add_internal_call run in GC Safe mode since
mono/mono@5756ba4b46 in order for hybrid suspend
to be a transparent replacement for preemptive suspend (the old default). The
icalls in GC Unsafe mode have a responsibility not to block indefinitely
without manually performing a thread state transition to GC Safe mode, and in
return they avoid a thread state transition when the icall is invoked from a
managed method.
`mono_jit_set_aot_only` is deprecated and accidentally broke with
https://github.com/mono/mono/pull/7887
This should fix device tests with `mono-2018-06`
This makes exception marshaling work with Xamarin.Mac apps that use the system
mono (such as Visual Studio for Mac, and assuming at least a v5.12 system
mono).
https://github.com/xamarin/xamarin-macios/issues/4271
mono_set_pending_exception is a private mono symbol, which means we won't find
it when using the system mono (as a dynamic library). In that case, we'd
abort.
Instead try to call mono_raise_exception, and hope for the best. It will leak
somewhat, but that's still better than asserting.
This changes the generated wrapper function from:
```c
MONO_API void
mono_set_pending_exception (MonoException * exc)
{
if (mono_set_pending_exception_func == NULL)
xamarin_assertion_message ("Could not load mono_set_pending_exception\n");
return mono_set_pending_exception_func (exc);
}
```
to
```c
MONO_API void
mono_set_pending_exception (MonoException * exc)
{
if (mono_set_pending_exception_func == NULL)
return mono_raise_exception (exc);
return mono_set_pending_exception_func (exc);
}
```
Also this only applies to Xamarin.Mac apps that use the system mono (such as VSfM).
https://bugzilla.xamarin.com/show_bug.cgi?id=59979
The two functions mono_class_is_nullable and mono_class_get_nullable_param are
private mono symbols, which means we can't call them when using Xamarin.Mac
with libmono from a dynamic library.
Implement a fallback for this case, where we call a managed method when these
functions are not available (and restrict this workaround to Xamarin.Mac only,
since it's not needed for Xamarin.iOS).
* [runtime] Fix broken indentation to make code less confusing.
* [runtime] Rework initialization for Xamarin.Mac extensions.
1. Delay the Application.Init execution from step 6 in the initialization
sequence, to when we'd run the managed Main function for a normal app. This
makes the code a bit easier to reason about, since both code paths behave
more similar. It's also matches the initialization documentation better
(step 6 is "find the executable", not "find the executable and run
Application.Init").
2. Install custom callbacks for mono's logging function just before calling
Application.Init. We already install these custom callbacks in
xamarin_initialize, but that doesn't help much if something goes wrong
before xamarin_initialize is called (and there's no harm in doing this
twice).
3. Treat the extension dll as an entry assembly, make the path to the entry
assembly available to managed code, and load this assembly if
Assembly.GetEntryAssembly can't find it (which happens for extensions,
since there's no entry point as Assembly.GetEntryAssembly defines an entry
assembly).
This fixes launching of Xamarin.Mac extensions.
* [runtime] Spaces -> tabs.
Managed exception marshaling interferes with the debugger, because it adds
exception handlers to executing code, which makes the Mono runtime think an
exception is handled when logically it's not (although technically it is).
The consequence is that the IDEs will only be notified when we re-throw the
exception after catching it, making it impossible for the IDEs to stop when
the exception is thrown (they will instead stop when we re-throw the
exception).
So disable managed exception marshaling (unless the user changed the default
behavior) when a debugger is attached.
This is the same behavior as Xamarin.Android.
https://bugzilla.xamarin.com/show_bug.cgi?id=45116
The base directory and config file name is normally set automatically
when we ask Mono to execute the Main function, but in the case of extensions,
there is no Main function, so these values are not set, causing some
features (reflection-only assembly load) to not work correctly.
https://bugzilla.xamarin.com/show_bug.cgi?id=42784
* Restore the mono_jit_thread_attach signature to how it's in
the latest stable.
* Don't use the new attach/detach methods when using the dynamic
mono runtime, since the methods aren't available in any released
version of mono. Also XM doesn't support coop yet, so it's not
needed.
* And finally don't use the new attach/detach methods for anything
that isn't building using mono/master (iow only watchOS). This
should be changed once the rest of the products starts using
mono/master again.