Merge pull request #2587 from lambdageek/monoerror-api-cleanup-mistakes

[runtime] Better error handling in mono_{assembly,module_file}_get_object

Merge pull request #2590 from esdrubal/wcf_req

BCL changes required by dotnet/wcf

Merge pull request #2595 from ludovic-henry/tests-sgen

[tests] Remove manual for loop to run sgen tests and use different make targets

[reflection] Better error behavior for API functions

mono_assembly_get_object and mono_module_file_get_object should return
NULL on failure without raising an exception.

[tests] Remove manual for loop to run sgen tests and use different make targets

Merge pull request #2598 from dellis1972/master

[msbuild] Registered the XmlPeek Build Task in the Microsoft.Common.tasks

[msbuild] Registered the XmlPeek Build Task in the Microsoft.Common.tasks

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=36183
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=38638

The previous commit () was incomplete, while it added the source
file for XmlPeek it did not register them in the appropriate
MSBuild tasks files. As a result the XmlPeek task cannot be used.

[aot] Fix the check in mono_aot_get_plt_entry () for thumb code, use 'code-4' instead of 'code', since the latter points to after a call, so it could point outside the range of llvm code. Fixes #36723.

[jit] Add a fastpath to Monitor.Enter () which doesn't have a wrapper, and add a slowpath which has a wrapper, so async stack traces work for threads blocked on monitors. Fixes #38525.

Fix a warning.

[jit] Fix the peephole optimization added by 9fc7c1de3a2f7d42c732b20e272d9d6693720012, compare_imm+cond_exc_imm can only be eliminated if the comparison is false.

Remove table that was not licensed under MIT

[Mono.Security]: MonoTlsProviderFactory.GetProvider(string) now returns null on error.

(cherry picked from commit 7f965e8220a67f3d806fb410e99ad453bddbe3bc)

Merge pull request #2591 from gofman/cherry-branch

[System.Windows.Forms] Recreate FosterWindow when required in XplatUIWin32

Merge pull request #2594 from akoeplinger/fix-facade-lookup-when-mono-path-overriden

[metadata] Fix Facades lookup in assembly.c when MONO_PATH is set

[profiler] Remove perf_event.h from EXTRA_DIST, too.

[profiler] Only include perf_event.h when actually needed, and use the system header.

[profiler] Remove the bundled perf_event.h header.

Bundling this in Mono is technically a GPL violation. We need to switch to the
system <linux/perf_event.h> header.

[Mono.Security]: Add 'MonoTlsProviderFactory.GetProvider(string)'.

Similar to 'SetDefaultProvider(string)', but return the provider instead
of installing it.

(cherry picked from commit 024241f424062a41f35061cd851f0923e25f16c7)

[llvmonly] Remove some leftover debugging code.

[swf] Flow SynchronizationContext through ExecutionContext. Fixes #38599

[metadata] Fix Facades lookup in assembly.c when MONO_PATH is set

When MONO_PATH is set, the corlib lookup returns early on in mono_assembly_load_corlib (),
without adding the Facades dir to default_path.

This causes any app/library that relies on the facades to fail at runtime.

Fixing this by always doing the Facades lookup when returning the found corlib image.

[corlib] Adds property AccessToken to WindowsIdentity

System.Security.Principal.WindowsIdentity.AccessToken is required for
dornet/wcf to compile.

Impelements IDisposable in X509Store

This class implement IDisposable in .NET and dotnet/wcf depends on this
to compile.

[System.Windows.Forms] Recreate FosterWindow when required in XplatUIWin32

Fixes #38614

[System.Net.Security] Adds NegotiateStream methods

System.Net.Security was missing some methods that are used by
dotnet/wcf.

[corlib] Added missing properties to EventAttribute

[corlib] Use correct max/min value for DateTime overflows. Fixes #35876

[System] Simple readability changes to SimpleAsyncResult

[jit] Add a peephole optimization to remove the ldaddr+compare_imm 0+cond_exc checks inserted when using explicit null checks.

[llvmonly] Disable the 'overriding the module target triple with' clang warning when compiling the bitcode files.

[llvmonly] Fix a few issues passing and returning vtypes smaller than one machine word.

[llvmonly] Fix the locking in the gsharedvt wrapper creation functions.

Merge pull request #2584 from lewurm/fix-mobile-compilation

[bcl] fix compilation of test on mobile

although a nunit category is specified, the compilation still failed on mobile.

[bcl] fix compilation of test on mobile

fix for the following problem:
> [13:33:37] src/System/Test/System.Diagnostics/ProcessTest.cs(1048,19): error CS0103: The name `GetCrossPlatformStartInfo' does not exist in the current context

Merge pull request #2582 from ludovic-henry/fix-threadpool-starvation

[threadpool] Improve the monitor thread heuristic

Because the ThreadPool heuristic is optimized for short lived work item, it has more difficulty when executing long lived work item. That case can lead to a starvation of the worker threads: they are all doing work, while there is outstanding request, and these requests are not satisfied because we reached the max number of working thread.

To fix that issue, we have the monitor thread, whose sole job is to unstuck this kind of starvation cases. Unfortunately, it only works when all the worker threads are in the ThreadState.WaitSleepJoin state, which excludes the case of calling an IO operation in a Task. That includes the case of FileStream.BeginRead/Write/... which implementation can be simplified as follows: FileStream.BeginRead(...) -> Task.Run(() => FileStream.Read(...)).

The way we implement it in this commit is: every MONITOR_INTERVAL (500ms here), we check if there is any outstanding request, and if so, we assume that we are in the starvation case, and we simply increase the max number of working thread. Also to reduce the number of false positives, we do that only if there has been no completed work item for more than at least MONITOR_INTERVAL (in case of low CPU usage, more otherwise, see monitor_sufficient_delay_since_last_dequeue). This case is typically the case where we have all working thread stuck in long running work items.

Finally we increase the monitor interval from 100ms to 500ms so we guarantee we do not create more than 2 threads per second in the monitor thread. That is the value used by the old threadpool.

[Docs] handle code-markdown with dots on the names

[Docs] Continue to improve the Mono runtime documentation

Merge pull request #2570 from lambdageek/monoerror-reflection-bubble-2

[reflection] Grab bag of MonoError commits

[threadpool] Improve the monitor thread heuristic

Because the ThreadPool heuristic is optimized for short lived work item, it has more difficulty when executing long lived work item. That case can lead to a starvation of the worker threads: they are all doing work, while there is outstanding request, and these requests are not satisfied because we reached the max number of working thread.

To fix that issue, we have the monitor thread, whose sole job is to unstuck this kind of starvation cases. Unfortunately, it only works when all the worker threads are in the ThreadState.WaitSleepJoin state, which excludes the case of calling an IO operation in a Task. That includes the case of FileStream.BeginRead/Write/... which implementation can be simplified as follows: FileStream.BeginRead(...) -> Task.Run(() => FileStream.Read(...)).

The way we implement it in this commit is: every MONITOR_INTERVAL (500ms here), we check if there is any outstanding request, and if so, we assume that we are in the starvation case, and we simply increase the max number of working thread. Also to reduce the number of false positives, we do that only if there has been no completed work item for more than at least MONITOR_INTERVAL (in case of low CPU usage, more otherwise, see monitor_sufficient_delay_since_last_dequeue). This case is typically the case where we have all working thread stuck in long running work items.

Finally we increase the monitor interval from 100ms to 500ms so we guarantee we do not create more than 2 threads per second in the monitor thread. That is the value used by the old threadpool.

[reflection] Fix decl of mono_image_create_token

For the DISABLE_REFLECTION_EMIT case

[reflection] Mark mono_custom_attrs_construct external only

The function mono_custom_attrs_construct_by_type is available for the
runtime (though currently static) and uses MonoError for error handling.

[reflection] Use MonoError in mono_reflection_marshal_as_attribute_from_marshal_spec

[runtime] Use MonoError for mono_event_get_object

Mark mono_event_get_object external only.
Runtime should use mono_event_get_object_checked.

[runtime] Use MonoError for mono_property_get_object

Mark mono_property_get_object external only.
Runtime should use mono_property_get_object_checked.

[reflection] Push MonoError through some static functions

[debugger] Don't call buffer_add_objid with NULL

Fixup 64778857e4652ccac18c6fbf990f3e7cc69fa275

[runtime] Cleanup MonoError after mono_runtime_try_invoke

If both an exception exc is set and the MonoError is not ok, we could
leak the MonoError memory.  Explicitly cleanup.

[mini] Use catchExcInMonoError to decide if exc should be embedded in MonoError

Do the dyn_runtime_invoke decision the same way as other invokes.

Fixup to 45bd9bb5d50e6cbd806a5e95696656eedad3bb78

[runtime] Don't raise MonoError when unloading appdomain

There's no managed code calling mono_domain_try_unload, so raising was
wrong.  Thread the error out through exc which gets checked by callers.

Fixup for 45bd9bb5d50e6cbd806a5e95696656eedad3bb78

[Docs] document one of our most key APIs: mono_add_internal_call

[Docs] Improved the rendering, added some docs

Merge pull request #2579 from ludovic-henry/fix-asyncresult-unhandledexception

[AsyncResult] Fix unhandled exception behaviour in AsyncCallback

The AsyncCallback is called after the BeginInvoke has completed. In all cases, this AsyncCallback is called on the ThreadPool, meaning that an unhandled exception would lead to a process crash.

The correct behaviour, after verification on .NET, is to not swallow the exception, and to properly crash the process.

@monojenkins merge

[AsyncResult] Fix unhandled exception behaviour in AsyncCallback

The AsyncCallback is called after the BeginInvoke has completed. In all cases, this AsyncCallback is called on the ThreadPool, meaning that an unhandled exception would lead to a process crash.

The correct behaviour, after verification on .NET, is to not swallow the exception, and to properly crash the process.

[corlib] AppContext from reference source

[Docs] Use an external style sheet, prefix the css classes with mapi to isolate, fix various processing problems

Merge pull request #2578 from akoeplinger/fix-hardcoded-mono-2.0-path

[metadata] Fix hardcoded mono/2.0 path in assembly.c

[llvmonly] Compile the bitcode files using -O2.

Merge pull request #2577 from xmcclure/bugzilla-37834

Recognize OS X file "locked" state (fixes #37834)

Quick fix for https://bugzilla.xamarin.com/show_bug.cgi?id=37834

IOLayer is_file_writable/System.IO.File.GetAttributes on posix systems looks only at the unix file permissions and does not consider special OS flags. This leads to an easily end-user-triggered bug on OS X if a mono app (the bug was observed in Xamarin Studio) uses GetAttribute on a file which has been "Locked" using the checkbox in Finder Get Info. This patch recognizes the "uchg" flag for non-writability which Finder uses.

[llvmonly] Add unbox wrappers when invoking vtype instance methods through a delegate.

[Documentation] Fix the nesting of docs

[metadata] Fix hardcoded mono/2.0 path in assembly.c

The performance team discovered this on their bots using the Jenkins snapshot packages. Mono would fail to start with a message like:

```
The assembly mscorlib.dll was not found or could not be loaded.
It should have been installed in the `/opt/mono-2016.02.08+15.25.39/lib/mono/4.5/mscorlib.dll' directory.
```

The one odd thing is that they are using Mono installed in a path which is different from the prefix used during compilation.

It turns out that the runtime has a hardcoded check for lib/mono/2.0 in https://github.com/mono/mono/blob/7d5a7ea7ac324bb4ee63094ddcf8e20ae9ba4322/mono/metadata/assembly.c#L633-L637.
Since we recently stopped shipping 2.0 in the packages (we moved to 2.0-api for the reference assemblies) this directory wasn't there,
so the code in fallback() called into mono_config_get_assemblies_dir() which just returns the MONO_ASSEMBLIES preprocessor symbol.

That preprocessor symbol is defined to the value of --prefix during compilation, so Mono couldn't find corlib there as well since it's installed in another path which ultimately results in the above error message.

The fix is to change the hardcoded value to 4.5, which is what we established as the directory with the "latest" assemblies now.
Ideally we should find a way to stop hardcoding those paths in the runtime.

PS: I grepped through the runtime source to make sure we don't hardcode 2.0/3.5/4.0 elsewhere and only found one instance in a test.
I fixed it there as well, though the test looks suspicious since it hardcodes /usr ...

[docs] Improve the rendering of our API binding APIs and runtime API documentation

Support OS X "locked" state (fixes #37834)

IOLayer is_file_writable/System.IO.File.GetAttributes on posix systems
looks only at the unix file permissions and does not consider special
OS flags. This leads to an easily end-user-triggered bug on OS X if a
mono app (the bug was observed in Xamarin Studio) uses GetAttribute on
a file which has been "Locked" using the checkbox in Finder Get Info.
This patch recognizes the "uchg" flag for non-writability which Finder
uses.

Merge pull request #2555 from lambdageek/monoerror-mono_runtime_invoke-2

Use MonoError for mono_runtime_invoke

[mcs] Use $(PLATFORM_PATH_SEPARATOR) instead of ':' for MONO_PATH to fix Windows tests

./ was added to MONO_PATH in b5c2b5892f3ff4c104f701a4175b90989e9c7045, but the Unix path separator ':' doesn't work on Windows.

[msvc] Fix Debug build by disabling outdated projects in sln

Merge pull request #2571 from lambdageek/monoerror-mono_assembly_get_object

Use MonoError in mono_assembly_get_object

[System.Runtime.Caching] Make TestExpiredGetValues test more reliable

It failed twice on Jenkins over the weekend:

```
Test Case Failures:
1) MonoTests.System.Runtime.Caching.MemoryCacheTest.TestExpiredGetValues :   #EGV4
  Expected: 0
  But was:  9

at MonoTests.System.Runtime.Caching.MemoryCacheTest.TestExpiredGetValues () [0x0012b] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armel/mcs/class/System.Runtime.Caching/Test/System.Runtime.Caching/MemoryCacheTest.cs:1304
```

We're sleeping just as long as the expiry time of the cache items (1s) which might not be enough.
Bumping the sleep time should fix this.

[readme] Clarify --enable-parallel-mark description

It's Boehm only and not enabled by default on some platforms (e.g. it's disabled on OSX).

[runtime] Switch to mono_runtime_invoke_checked and mono_runtime_try_invoke

Mark mono_runtime_invoke external only.
Runtime should use mono_runtime_invoke_checked and mono_runtime_try_invoke.

[runtime] Use MonoError for mono_jit_runtime_invoke and mono_llvmonly_runtime_invoke

[reflection] Use MonoError in mono_assembly_get_object

Mark mono_assembly_get_object external only.
Runtime should use mono_assembly_get_object_checked.

Also propagated MonoError through a few static functions in reflection:
mono_reflection_get_type_internal () and
mono_reflection_get_type_internal_dynamic ()

Merge pull request #2574 from abrasive/gcc5_fix_gc

libgc: use __builtin_frame_address in GC_approx_sp

Merge pull request #2575 from alexrp/master

[profiler] Fix a rare crash when sending SIGPROF to a starting thread.

[profiler] Fix a rare crash when sending SIGPROF to a starting thread.

When sample profiling is enabled and we send a SIGPROF signal to a thread that
hasn't yet transitioned to a running state (e.g. STATE_RUNNING), the signal can
sometimes be delivered at such an early point that libc has not even finished
initializing TLS for that thread yet. This is problematic because we then go
right on to crash in the SIGPROF signal handler when we try to save errno. We
then further crash in the SIGSEGV handler because we can't access the jit_tls
variable either.

The fix is fairly simple: Only send SIGPROF to threads that have transitioned
to a running state. Technically, TLS is initialized 'much' earlier than when
this state transition happens, but since the worst thing that can happen is
that we miss one sampling event (i.e. ~1sec by default) right at the beginning
of the thread's lifetime, this simple fix is good enough.

This crash seemingly only happened on OS X.

[llvmonly] Disable tail calls as they break stack traces.

[llvm] Make the stack walk code return.

libgc: use __builtin_frame_address in GC_approx_sp

With GCC 5.x, the compiler optimises away the dummy load used to
estimate the stack pointer address in GC_approx_sp; it returns
zero. This leads to segfaults when embedding Mono.

Instead, use __builtin_frame_address, which GCC's libgc uses for
the same purpose.

[llvmonly] Compile the bitcode files using -O2 (only in desktop llvmonly mode).

[llvm] When storing valuetypes received in registers to the stack, store only the value parts of the register, the upper bits might container garbage.

Merge pull request #2567 from lambdageek/monoerror-mono_module_file_get_object

[reflection] Use MonoError in mono_module_file_get_object

[jit] Disable to returning of trampolines from mini_jit_info_table_find () to see whenever that fixes failures on wrench.

[llvmonly] Remove the mono_llvmonly_get_calling_assembly () workaround since stack walks work in llvmonly mode now.

[reflection] Use MonoError in mono_module_file_get_object

Mark mono_module_file_get_object external only.
Use mono_module_file_get_object_checked in runtime code.

Fix the build.

Merge pull request #2569 from xmcclure/gshared-enable

Miscellaneous minor improvements around amd64 aot

Fixed compiler to wrap paths with embedded spaces when calling external tools.

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=34498.

[corlib] Disable ThreadLocalTests.DisposeOnThreadExit on MonoTouch, it's randomly failing.

Merge pull request #2572 from akoeplinger/fix-monodoc-language

[monodoc] Fix literal formatting on systems where decimal separator is not a dot

[llvmonly] Various small fixes. Make mono_llvm_throw_exception etc. directly callable in static mode. Add support for directly calling pinvoke methods. Fix an assertion during EH.

[Docs] More API docs

[llvmonly] Don't set the invariant.load flag on loads from the GOT, they are initialized by a call to init_method () so they are not completely invariant.

Revert "[jit] Don't allocate memory for unused vreg"

This reverts commit 137c0999cc8e1e9171c7703af9b013f2e43731f5.

Revert this as leads to a memory overwrite on x86:

defs [ins->dreg + 1] = NULL;

Move some amd64 constants out of source into header

Clarify trampoline error message in aot-runtime

Merge pull request #2566 from lambdageek/monoerror-mono_module_get_object

[reflection] Use MonoError for mono_module_get_object

Merge pull request #2535 from lambdageek/monoerror-reflection-bubble

[reflection] Push MonoError through misc methods

[System] Remove explicit sdk target from CSharpCodeCompiler

[io-layer] Print from which pipe we just read