Giter Club home page Giter Club logo

mono / mono Goto Github PK

View Code? Open in Web Editor NEW
10.8K 532.0 3.8K 565.67 MB

Mono open source ECMA CLI, C# and .NET implementation.

Home Page: https://www.mono-project.com

License: Other

Shell 0.21% Python 0.09% C# 90.76% DTrace 0.01% C 6.75% C++ 0.08% Assembly 0.01% Makefile 0.41% HTML 0.20% XSLT 0.01% CSS 0.01% JavaScript 0.44% Perl 0.02% Java 0.01% PLSQL 0.02% PLpgSQL 0.86% Smalltalk 0.01% Ruby 0.01% Batchfile 0.03% M4 0.10%
xamarin android ios dotnet garbage-collector runtime jit csharp

mono's Introduction

Mono is a software platform designed to allow developers to easily create cross platform applications. It is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime.

The Mono project is part of the .NET Foundation

Join us on Discord in the #monovm channel:

Contents

  1. Compilation and Installation
  2. Using Mono
  3. Directory Roadmap
  4. Contributing to Mono
  5. Reporting bugs
  6. Configuration Options
  7. Working with Submodules

Build Status

Public CI: Azure Pipelines

Legacy Jenkins CI (no longer available publicly):

OS Architecture Status
Debian 9 amd64 debian-9-amd64
Debian 9 i386 debian-9-i386
Debian 9 armel debian-9-armel
Debian 9 armhf debian-9-armhf
Debian 9 arm64 debian-9-arm64
OS X amd64 osx-amd64
OS X i386 osx-i386
Windows amd64 windows-amd64
Windows i386 windows-i386
CentOS s390x (cs) centos-s390x
Debian 9 ppc64el (cs) debian-9-ppc64el
AIX 6.1 ppc64 (cs) aix-ppc64
FreeBSD 12 amd64 (cs) freebsd-amd64

(cs) = community supported architecture

Compilation and Installation

Building the Software

Please see our guides for building Mono on Mac OS X, Linux and Windows.

Note that building from Git assumes that you already have Mono installed, so please download and install the latest Mono release before trying to build from Git. This is required because the Mono build relies on a working Mono C# compiler to compile itself (also known as bootstrapping).

If you don't have a working Mono installation

If you don't have a working Mono installation, you can try a slightly more risky approach: getting the latest version of the 'monolite' distribution, which contains just enough to run the 'mcs' compiler. You do this with:

# Run the following line after ./autogen.sh
make get-monolite-latest

This will download and place the files appropriately so that you can then just run:

make

The build will then use the files downloaded by make get-monolite-latest.

Testing and Installation

You can run the mono and mcs test suites with the command: make check.

Expect to find a few test suite failures. As a sanity check, you can compare the failures you got with https://jenkins.mono-project.com/.

You can now install mono with: make install

You can verify your installation by using the mono-test-install script, it can diagnose some common problems with Mono's install. Failure to follow these steps may result in a broken installation.

Using Mono

Once you have installed the software, you can run a few programs:

  • mono program.exe runtime engine

  • mcs program.cs C# compiler

  • monodis program.exe CIL Disassembler

See the man pages for mono(1), mcs(1) and monodis(1) for further details.

Directory Roadmap

  • acceptance-tests/ - Optional third party test suites used to validate Mono against a wider range of test cases.

  • data/ - Configuration files installed as part of the Mono runtime.

  • docs/ - Technical documents about the Mono runtime.

  • external/ - Git submodules for external libraries (Newtonsoft.Json, ikvm, etc).

  • ikvm-native/ - Glue code for ikvm.

  • libgc/ - The (deprecated) Boehm GC implementation.

  • llvm/ - Utility Makefiles for integrating the Mono LLVM fork.

  • m4/ - General utility Makefiles.

  • man/ - Manual pages for the various Mono commands and programs.

  • mcs/ - The class libraries, compiler and tools

    • class/ - The class libraries (like System.*, Microsoft.Build, etc.)

    • mcs/ - The Mono C# compiler written in C#

    • tools/ - Tools like gacutil, ikdasm, mdoc, etc.

  • mono/ - The core of the Mono Runtime.

    • arch/ - Architecture specific portions.

    • benchmark/ - A collection of benchmarks.

    • btls/ - Build files for the BTLS library which incorporates BoringSSL.

    • cil/ - Common Intermediate Representation, XML definition of the CIL bytecodes.

    • dis/ - CIL executable Disassembler.

    • eglib/ - Independent implementation of the glib API.

    • metadata/ - The object system and metadata reader.

    • mini/ - The Just in Time Compiler.

    • profiler/ - The profiler implementation.

    • sgen/ - The SGen Garbage Collector implementation.

    • tests/ - The main runtime tests.

    • unit-tests/ - Additional runtime unit tests.

    • utils/ - Utility functions used across the runtime codebase.

  • msvc/ - Logic for the MSVC / Visual Studio based runtime and BCL build system. The latter is experimental at the moment.

  • packaging/ - Packaging logic for the OS X and Windows Mono packages.

  • po/ - Translation files.

  • runtime/ - A directory that contains the Makefiles that link the mono/ and mcs/ build systems.

  • samples/ - Some simple sample programs on uses of the Mono runtime as an embedded library.

  • scripts/ - Scripts used to invoke Mono and the corresponding program.

  • support/ - Various support libraries.

  • tools/ - A collection of tools, mostly used during Mono development.

Contributing to Mono

Before submitting changes to Mono, please review the contribution guidelines. Please pay particular attention to the Important Rules section.

Reporting bugs

To submit bug reports, please open an issue on the mono GitHub repo.

Please use the search facility to ensure the same bug hasn't already been submitted and follow our guidelines on how to make a good bug report.

Configuration Options

The following are the configuration options that someone building Mono might want to use:

  • --with-sgen=yes,no - Generational GC support: Used to enable or disable the compilation of a Mono runtime with the SGen garbage collector.

    • On platforms that support it, after building Mono, you will have both a mono-boehm binary and a mono-sgen binary. mono-boehm uses Boehm, while mono-sgen uses the Simple Generational GC.
  • --with-libgc=[included, none] - Selects the default Boehm garbage collector engine to use.

    • included: (slightly modified Boehm GC) This is the default value for the Boehm GC, and it's the most feature complete, it will allow Mono to use typed allocations and support the debugger.

    • none: Disables the inclusion of a Boehm garbage collector.

    • This defaults to included.

  • --enable-cooperative-suspend

    • If you pass this flag the Mono runtime is configured to only use the cooperative mode of the garbage collector. If you do not pass this flag, then you can control at runtime the use of the cooperative GC mode by setting the MONO_ENABLE_COOP_SUSPEND flag.
  • --with-tls=__thread,pthread

    • Controls how Mono should access thread local storage, pthread forces Mono to use the pthread APIs, while __thread uses compiler-optimized access to it.

    • Although __thread is faster, it requires support from the compiler, kernel and libc. Old Linux systems do not support with __thread.

    • This value is typically pre-configured and there is no need to set it, unless you are trying to debug a problem.

  • --with-sigaltstack=yes,no

    • Experimental: Use at your own risk, it is known to cause problems with garbage collection and is hard to reproduce those bugs.

    • This controls whether Mono will install a special signal handler to handle stack overflows. If set to yes, it will turn stack overflows into the StackOverflowException. Otherwise when a stack overflow happens, your program will receive a segmentation fault.

    • The configure script will try to detect if your operating system supports this. Some older Linux systems do not support this feature, or you might want to override the auto-detection.

  • --with-static_mono=yes,no

    • This controls whether mono should link against a static library (libmono.a) or a shared library (libmono.so).

    • This defaults to yes, and will improve the performance of the mono program.

    • This only affects the `mono' binary, the shared library libmono.so will always be produced for developers that want to embed the runtime in their application.

  • --with-xen-opt=yes,no - Optimize code for Xen virtualization.

    • It makes Mono generate code which might be slightly slower on average systems, but the resulting executable will run faster under the Xen virtualization system.

    • This defaults to yes.

  • --with-large-heap=yes,no - Enable support for GC heaps larger than 3GB.

    • This only applies only to the Boehm garbage collector, the SGen garbage collector does not use this configuration option.

    • This defaults to no.

  • --enable-small-config=yes,no - Enable some tweaks to reduce memory usage and disk footprint at the expense of some capabilities.

    • Typically this means that the number of threads that can be created is limited (256), that the maximum heap size is also reduced (256 MB) and other such limitations that still make mono useful, but more suitable to embedded devices (like mobile phones).

    • This defaults to no.

  • --with-ikvm-native=yes,no - Controls whether the IKVM JNI interface library is built or not.

    • This is used if you are planning on using the IKVM Java Virtual machine with Mono.

    • This defaults to yes.

  • --with-profile4=yes,no - Whether you want to build the 4.x profile libraries and runtime.

    • This defaults to yes.
  • --with-libgdiplus=installed,sibling,<path> - Configure where Mono searches for libgdiplus when running System.Drawing tests.

    • It defaults to installed, which means that the library is available to Mono through the regular system setup.

    • sibling can be used to specify that a libgdiplus that resides as a sibling of this directory (mono) should be used.

  • Or you can specify a path to a libgdiplus.

  • --enable-minimal=LIST

    • Use this feature to specify optional runtime components that you might not want to include. This is only useful for developers embedding Mono that require a subset of Mono functionality.

    • The list is a comma-separated list of components that should be removed, these are:

      • aot: Disables support for the Ahead of Time compilation.

      • attach: Support for the Mono.Management assembly and the VMAttach API (allowing code to be injected into a target VM)

      • com: Disables COM support.

      • debug: Drop debugging support.

      • decimal: Disables support for System.Decimal.

      • full_messages: By default Mono comes with a full table of messages for error codes. This feature turns off uncommon error messages and reduces the runtime size.

      • generics: Generics support. Disabling this will not allow Mono to run any 2.0 libraries or code that contains generics.

      • jit: Removes the JIT engine from the build, this reduces the executable size, and requires that all code executed by the virtual machine be compiled with Full AOT before execution.

      • large_code: Disables support for large assemblies.

      • logging: Disables support for debug logging.

      • pinvoke: Support for Platform Invocation services, disabling this will drop support for any libraries using DllImport.

      • portability: Removes support for MONO_IOMAP, the environment variables for simplifying porting applications that are case-insensitive and that mix the Unix and Windows path separators.

      • profiler: Disables support for the default profiler.

      • reflection_emit: Drop System.Reflection.Emit support

      • reflection_emit_save: Drop support for saving dynamically created assemblies (AssemblyBuilderAccess.Save) in System.Reflection.Emit.

      • shadow_copy: Disables support for AppDomain's shadow copies (you can disable this if you do not plan on using appdomains).

      • simd: Disables support for the Mono.SIMD intrinsics library.

      • ssa: Disables compilation for the SSA optimization framework, and the various SSA-based optimizations.

  • --enable-llvm

    • This enables the use of LLVM as a code generation engine for Mono. The LLVM code generator and optimizer will be used instead of Mono's built-in code generator for both Just in Time and Ahead of Time compilations.

    • See https://www.mono-project.com/docs/advanced/mono-llvm/ for the full details and up-to-date information on this feature.

    • You will need to have an LLVM built that Mono can link against.

  • --enable-big-arrays - Enable use of arrays with indexes larger than Int32.MaxValue.

    • By default Mono has the same limitation as .NET on Win32 and Win64 and limits array indexes to 32-bit values (even on 64-bit systems).

    • In certain scenarios where large arrays are required, you can pass this flag and Mono will be built to support 64-bit arrays.

    • This is not the default as it breaks the C embedding ABI that we have exposed through the Mono development cycle.

  • --enable-parallel-mark

    • Use this option to enable the garbage collector to use multiple CPUs to do its work. This helps performance on multi-CPU machines as the work is divided across CPUS.

    • This option is not currently the default on OSX as it runs into issues there.

    • This option only applies to the Boehm GC.

  • --enable-dtrace

    • On Solaris and MacOS X builds a version of the Mono runtime that contains DTrace probes and can participate in the system profiling using DTrace.
  • --disable-dev-random

    • Mono uses /dev/random to obtain good random data for any source that requires random numbers. If your system does not support this, you might want to disable it.

    • There are a number of runtime options to control this also, see the man page.

  • --with-csc=roslyn,mcs,default

    • Use this option to configure which C# compiler to use. By default the configure script will pick Roslyn, except on platforms where Roslyn does not work (Big Endian systems) where it will pick mcs.

      If you specify "mcs", then Mono's C# compiler will be used. This also allows for a complete bootstrap of Mono's core compiler and core libraries from source.

ย  If you specify "roslyn", then Roslyn's C# compiler will be used. This currently uses Roslyn binaries.

  • --enable-nacl

    • This configures the Mono compiler to generate code suitable to be used by Google's Native Client: https://code.google.com/p/nativeclient/

    • Currently this is used with Mono's AOT engine as Native Client does not support JIT engines yet.

  • --enable-wasm

    • Use this option to configure mono to run on WebAssembly. It will set both host and target to the WebAssembly triplet. This overrides the values passed to --host or --target and ignored what config.sub guesses.

      This is a workaround to enable usage of old automake versions that don't recognize the wasm triplet.

Working With Submodules

Mono references several external git submodules, for example a fork of Microsoft's reference source code that has been altered to be suitable for use with the Mono runtime.

This section describes how to use it.

An initial clone should be done recursively so all submodules will also be cloned in a single pass:

$ git clone --recursive [email protected]:mono/mono

Once cloned, submodules can be updated to pull down the latest changes. This can also be done after an initial non-recursive clone:

$ git submodule update --init --recursive

To pull external changes into a submodule:

$ cd <submodule>
$ git pull origin <branch>
$ cd <top-level>
$ git add <submodule>
$ git commit

By default, submodules are detached because they point to a specific commit. Use git checkout to move back to a branch before making changes:

$ cd <submodule>
$ git checkout <branch>
# work as normal; the submodule is a normal repo
$ git commit/push new changes to the repo (submodule)

$ cd <top-level>
$ git add <submodule> # this will record the new commits to the submodule
$ git commit

To switch the repo of a submodule (this should not be a common or normal thing to do at all), first edit .gitmodules to point to the new location, then:

$ git submodule sync -- <path of the submodule>
$ git submodule update --recursive
$ git checkout <desired new hash or branch>

The desired output diff is a change in .gitmodules to reflect the change in the remote URL, and a change in / where you see the desired change in the commit hash.

License

See the LICENSE file for licensing information, and the PATENTS.TXT file for information about Microsoft's patent grant.

Mono Trademark Use Policy

The use of trademarks and logos for Mono can be found here.

mono's People

Contributors

akoeplinger avatar alexanderkyte avatar alexischr avatar atsushieno avatar brzvlad avatar carlosalberto avatar dickp avatar esdrubal avatar garuma avatar gonzalop avatar grendello avatar harinath avatar illupus avatar ivanz avatar jaykrell avatar jbevain avatar jpobst avatar kumpera avatar lambdageek avatar lewurm avatar luhenry avatar marek-safar avatar migueldeicaza avatar monojenkins avatar radical avatar rolfbjarne avatar schani avatar slluis avatar tritao avatar vargaz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mono's Issues

Some profiler events are raised before profilers are loaded

After adding some debug logging to MONO_PROFILER_RAISE, I get this:

jit_chunk_created raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded
jit_code_buffer raised before a profiler was loaded

While these events are not super important, we should still see if anything can be done about it. We might have to load profilers before the global code manager is initialized.

ArrayTypeMismatchException when using array of generic ICollection<T> or IList<T>

Steps to Reproduce

  1. Run the following program:
using System.Collections.Generic;

public interface IFoo
{
  int MyInt { get; }
}

public class Bar : IFoo
{
  public int MyInt => 0;
}

class App {
  public static void Main ()
  {
    ICollection<IFoo> arr1 = new Bar[1] { new Bar() };
    ICollection<IFoo> arr2 = new Bar[1] { new Bar() };

    ICollection<IFoo>[] a2d = new ICollection<IFoo>[2] {
      arr1,
      arr2,
    };
  }
}

Expected Behavior

No exception thrown.

Actual Behavior

Throws an ArrayTypeMismatchException at last line of test code at runtime when using ICollection<T> or IList<T>.

System.ArrayTypeMismatchException: Attempted to access an element as a type incompatible with the array.
  at (wrapper stelemref) System.Object:virt_stelemref_interface (intptr,object)
  at App.Main () [0x0001f] in /Users/jon/tmp/csharp/gxa-1120.cs:19 

The following types are working properly as expected:

  • IEnumerable
  • IEnumerable<T>
  • ICollection
  • IList

Code is compiling successfully with all types.

Version Information

Visual Studio: 15.5.2
Mono: MonoAndroid70 / 4.0.30319 / 8.1.0.25
Android: 7.0
Kernel: 4.1.18-gdd36b34

On which platforms did you notice this

-[X] macOS
-[ ] Linux
-[ ] Windows
-[X] Xamarin.Android

Version Used:

Desktop macOS: 5.4.1.7 (2017-06/e66d9abbb27)
Xamarin.Android 8.1: d15-5-2017-06/950ea65

Haiku runtime termination issues with threads and SGen

  • Version: Mono JIT compiler version 5.11.0 (master/2b90049bcce Mon Dec 11 17:05:00 AST 2017)
    Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
    TLS: normal
    SIGSEGV: normal
    Notification: Thread + polling
    Architecture: amd64
    Disabled: none
    Misc: softdebug
    Interpreter: yes
    LLVM: supported, not enabled.
    GC: sgen
  • Platform: Haiku shredder 1 hrev51662 Dec 8 2017 18:40:07 x86_64 x86_64 Haiku [x86 is affected too]
  • Subsystem: mono/utils/mono-threads.c

The function suspend_sync_nolock causes an infinite loop after the program terminates and runtime cleanup is performed, For some reason, the conditions that break the loop (related to threading) are not met, and the sleep duration raises infinitely making any chance of breaking out of the loop increasingly unlikely.

To fix, the cause of the loop being unbroken must be found. (It may be prudent to just give up on the loop after a while too.) I'm uncertain if the problem is within Mono or Haiku either; I'm leaning towards Mono, which is why I'm filing here.

(NOTE: When debugging, I had to make this function non-static so I could set breakpoints properly on the function body, or Haiku's debugger was unaware of it. You can make the makefiles start Mono attached to the debugger by prefixing the mono executable name in runtime/mono-wrapper with "Debugger ".) (ALSO NOTE: If you want to reproduce this yourself, the build dependencies needed for Mono on Haiku are gettext and libtool. Note on x86 you will have to run setarch x86 to get GCC5.)

If this bug is fixed, then Roslyn should be able to successfully terminate and we may be able to successfully build the managed parts of Mono for a working Haiku build.

Remove code coverage support from the log profiler

We now have a dedicated coverage profiler that is working quite well and which we're exercising on CI. We also warn users who use the coverage option of the log profiler that they should switch to the new coverage profiler instead. All that's left is to remove the coverage support from the log profiler at some point.

Switch the JIT --trace code to using call context introspection

Now that the profiler API has full support for selective enter/leave instrumentation and simple/portable inspection of stack frames (arguments, locals, return value), we could implement the mono --trace functionality using this API. This would allow us to get rid of the arch-specific mono_arch_instrument_prolog and mono_arch_instrument_epilog, both of which are known to be somewhat unreliable (the reason we switched enter/leave instrumentation to using internal calls in the first place).

XBuild fails with "Error executing task CreateCSharpManifestResourceName: String literal not closed"

Hi... I found a strange little bug I really do not understand:

If have a .NET framework project serving files via HTTP(S). I also have some time script files which are Embedded Resources and get complied with the help of the tsconfig.json file. In Visual Studio 2017 CE everything is fine. But even with yesterdays mono version from GitHub I get the following error:

/home/ahzf/SWUpdatesAPI/CAUpdates.sln (default targets) ->
(Build target) -> /home/ahzf/SWUpdatesAPI/CAUpdates/CAUpdates.csproj (default targets) ->
/usr/local/lib/mono/xbuild/14.0/bin/Microsoft.CSharp.targets (CreateManifestResourceNames target) ->
                                        /usr/local/lib/mono/xbuild/14.0/bin/Microsoft.CSharp.targets: error : Error executing task CreateCSharpManifestResourceName: String literal not closed
                                         4 Warning(s)
                                         1 Error(s)

The problem seems to be the following bit stupid line of code in one of the type script files:

(versionDiv.querySelector("#repositoryId") as HTMLDivElement).innerHTML = "<a href=\"../../" + repositoryId + "\">" + repositoryId + "</a>";

When I change the double quotationย marks into single ones xbuild accepts everything and the complie error goes away:

(versionDiv.querySelector("#repositoryId") as HTMLDivElement).innerHTML = '<a href=\"../../' + repositoryId + '\">' + repositoryId + '</a>';

I'm not sure if this is really the mono source causing all the trouble:
https://github.com/mono/mono/blob/master/mcs/class/Microsoft.Build.Tasks/Microsoft.Build.Tasks/CreateCSharpManifestResourceName.cs

Does anyone know which intent lies behind CreateCSharpManifestResourceName.cs? Why is it parsing files? And why seems VS and tsc not having a problem with this line of code?

Best...
Achim

Finalizer Segment Fault

  1. Application Version: Trunk
  2. redhat 6.5
  3. intel x86
  4. Description:
    Running nunit runner we are getting a segment fault when the nunit running is exiting. After painful debugging of commits to the trunk I found the commit that was causing the problem. It was this one.

be9821f

I commented out the cached_module_cleanup(); and magically the segment faulting went away.

What I found was when nunitrunner was exiting , this method would get executed and in the middle of the executing I noticed the finalizers were running and in our finalizers we do c++ interop calls
To do c++ memory cleanup and its during the c++ cleanup it ends up crashing related to what seems to be happening in the cached_module_cleanup() process.

I put some debugging around the call and this is what I got:

Tests run: 306, Errors: 0, Failures: 0, Inconclusive: 0, Time: 54.5821201 seconds
Not run: 0, Invalid: 0, Ignored: 0, Skipped: 0

11MpiNUnitWrapper MPI Finalize called
1a
Deleting ObjectCatalog...

Still holding on to 11 objects
Segmentation fault (core dumped)
[root@cgy-itsec2 Release]# ls *core*

Note that the message 1a is printed just before the cached_module_cleanup() is called and 2a is called just after. Note there is no 2a message printed and the 'Deleting ObjectCatalog' message
Is coming from c++ and was initiated by one of our c# object finalizers.
So It looks like this cached_module_cleanup() method is getting called and in the middle of it .net finalizers are getting called and somehow this cleanup is messing up the finalizer calls.

My question is shouldnt it wait for the finalizers before doing this cleanup?

This is the dump of the core dump file:

(gdb) backtrace
#0 0x00007f9dd333878b in boost::detail::sp_counted_impl_pd<domainmodel::cppobjectcatalog::ObjectCatalog*, domainmodel::cppobjectcatalog::ObjectCatalog::Deleter>::dispose() ()
from /build/COFLOW/Bin/redhat6/x64/gcc/Release/libDrms.Server.compute.domainmodel.cppobjectcatalog.so
#1 0x00007f9dd3338691 in boost::shared_ptr<domainmodel::cppobjectcatalog::ObjectCatalog>::~shared_ptr() ()
from /build/COFLOW/Bin/redhat6/x64/gcc/Release/libDrms.Server.compute.domainmodel.cppobjectcatalog.so
#2 0x00007f9e1d5a0dba in __cxa_finalize () from /lib64/libc.so.6
#3 0x00007f9dd3336c83 in __do_global_dtors_aux () from /build/COFLOW/Bin/redhat6/x64/gcc/Release/libDrms.Server.compute.domainmodel.cppobjectcatalog.so
#4 0x00007ffc586b5e40 in ?? ()
#5 0x00007f9e1e47d829 in _dl_close_worker () from /lib64/ld-linux-x86-64.so.2
Backtrace stopped: frame did not save the PC

Note that its in the middle of some c++ code that was initiated by a c# objects finalizer when it crashed and the ObjectCatalog::Deleter is doing some cleanup related to some pinned objects on the .net side that are shared with c++.

That's are far as I could go without really knowing what the purpose of this cached_module_cleanup() is and why its happening here.

mkbundle missing features

Few issues found while demoing mkbundle:

  • The list of the downloaded targets keeps the zip extension, it should be plain (example: ~/.mono/targets/mono-5.4.0-ubuntu-12.04-x64.zip/bin). We should ask Jo to rename the files on the server
  • Not clear that we distribute the Boring TLS native payloads on the packages
  • Automatically bundle machine.config for --simple and --cross targets.

Version Used:

5.4.0.

Compile problem - error CS0006: Metadata file './../../../external/api-snapshot/profiles/net_4_x/System.Net.Http.dll' could not be found

Hello.

Not sure if this is the right place to report this; please close this if it is the wrong place.

Upon trying to compile:

http://download.mono-project.com/sources/mono/mono-5.9.0.569.tar.bz2

I ran into an error:

make[3]: Leaving directory '/Depot/Temp/mono-5.9.0.569/data'
make[2]: Leaving directory '/Depot/Temp/mono-5.9.0.569/data'
make[1]: Leaving directory '/Depot/Temp/mono-5.9.0.569/data'
Making install in runtime
make[1]: Entering directory '/Depot/Temp/mono-5.9.0.569/runtime'
cd /Depot/Temp/mono-5.9.0.569/mcs && make NO_DIR_CHECK=1 PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14 ' RUNTIME_HAS_CONSISTENT_GACDIR=yes prefix=/Programs/Mono/5.9.0.569 install-profiles
make[2]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs'
make profile-do--binary_reference_assemblies--install profile-do--net_4_x--install profile-do--xbuild_12--install profile-do--xbuild_14--install
make[3]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs'
make PROFILE=basic install
make[4]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs'
make[5]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs/build'
make install-local
make[5]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs/build'
make[5]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs/jay'
make install-local
make[6]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs/jay'
make[6]: Nothing to be done for 'install-local'.
make[6]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs/jay'
make[5]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs/jay'
make[5]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs/class'
make[6]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs/class/corlib'
make install-local
make[6]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs/class/corlib'
make[6]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs/class/Mono.Security'
make install-local
make[7]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs/class/Mono.Security'
(cd ../System; make ../../class/lib/basic/bare/System.dll)
make[8]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs/class/System'
make intermediate=bare/ ./../../class/lib/basic/bare/System.dll
make[9]: Entering directory '/Depot/Temp/mono-5.9.0.569/mcs/class/System'
CSC [bare/basic] System.dll
error CS0006: Metadata file './../../../external/api-snapshot/profiles/net_4_x/System.Net.Http.dll' could not be found
make[9]: *** [../../build/library.make:342: ../../class/lib/basic/bare/System.dll] Error 1
make[9]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs/class/System'
make[8]: *** [Makefile:160: ../../class/lib/basic/bare/System.dll] Error 2
make[8]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs/class/System'
make[7]: *** [Makefile:31: ../../class/lib/basic/bare/System.dll] Error 2
make[7]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs/class/Mono.Security'
make[6]: *** [../../build/rules.make:211: do-install] Error 2
make[6]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs/class/Mono.Security'
make[5]: *** [../build/rules.make:232: install-recursive] Error 1
make[5]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs/class'
make[4]: *** [build/rules.make:232: install-recursive] Error 1
make[4]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs'
make[3]: *** [Makefile:54: profile-do--basic--install] Error 2
make[3]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs'
make[2]: *** [Makefile:50: profiles-do--install] Error 2
make[2]: Leaving directory '/Depot/Temp/mono-5.9.0.569/mcs'
make[1]: *** [Makefile:601: install-exec] Error 2
make[1]: Leaving directory '/Depot/Temp/mono-5.9.0.569/runtime'
make: *** [Makefile:541: install-recursive] Error 1

My system is slackware, linux, 64 bit, gcc version is 7.2.0

I was able to compile mono from source a few weeks ago, on the
same system, so I am almost absolutely sure that the problem is
related to something in mono. But I have too little domain specific
knowledge to really tell what went wrong. Hopefully you guys can
spot the problem. I'll try with another release perhaps in 2 weeks
or so - if you don't hear another report from me then that should
mean that the release in 2 weeks or so, worked. :)

To make the error more explicit, it was:

error CS0006: Metadata file './../../../external/api-snapshot/profiles/net_4_x/System.Net.Http.dll' could not be found

Parallelize log buffer parsing in LogProcessor

Since we read log buffers into a MemoryStream before actually parsing events from them, it should be entirely possible to parse multiple buffers in parallel, sort them by arrival order, and then actually process the parsed events from them serially.

Rare shutdown crash in profiler stress tests

Example: https://jenkins.mono-project.com/job/test-mono-mainline-linux-profilerstress-x86-x64/label=high-mem-ubuntu-1404-i386/500/testReport/junit/MonoTests/profiler-stress/couchbase/

It looks like we try to call mono_method_full_name on a MonoMethod whose signature contains a type that's already been freed. This happens because we keep MonoMethod pointers around in the profiler for longer than we should - see #6171. The fix will probably be similar to that issue.

[Unix] w32process-unix.c mono_w32process_signal_finished breaks all child process status queries

This issue refers to this code here:

do {
do {
pid = waitpid (-1, &status, WNOHANG);
} while (pid == -1 && errno == EINTR);
if (pid <= 0)
break;

This change severely impacts process management for Unix-based applications.

waitpid(-1,...) reaps all zombie child processes of the calling process. See man waitpid. After a child process is reaped, it can no longer be queried. Because this reaping step is invoked via the SIGCHLD signal, all zombie children of the calling process are reaped every time any child process terminates, regardless of whether that child process was tracked by Mono.

The impact of this is that apps using Mono that spawn their own child processes (outside of Mono's w32process API) cannot call wait on children, cannot query exit codes, and so on. A call to waitpid(my_child_pid,...) will return ECHILD for "no such child" because Mono has already cleaned up the child the moment SIGCHLD was raised.

A suggested fix would be to only wait on processes that Mono owns, rather than all child processes for the calling process:

	for (process = processes; process; process = process->next) {
		do {
			pid = waitpid (process->pid, &status, WNOHANG);
		} while (pid == -1 && errno == EINTR);

		if (process->pid != pid) // catches both no-change status (0) and error codes (-1)
			continue;
		if (process->signalled)
			continue;

		process->signalled = TRUE;
		process->status = status;
		mono_os_sem_post (&process->exit_sem);
		mono_memory_barrier ();
		/* Mark this as freeable, the pointer becomes invalid afterwards */
		process->freeable = TRUE;
		break;
	}

fork() - Mono.Unix.Native

I have noticed that in mono/mcs/class/Mono.Posix/Mono.Unix.Native/Syscall.cs fork() is #if'd out with the message "DO NOT directly call fork(2); it bypasses essential shutdown code. Use System.Diagnostics.Process instead".

What happens specifically? fork() starts a process, it does not shut anything down? fork() should just work, does it not (effectively (copy on write)) copy the entire VM which then each shuts down independently? fork() does work in Python on Unix (multiprocessing module).

fork() is powerful, it supports using processes as an alternative to threads. One can not test for a one in a million race condition. System.Diagnostics.Process only replaces fork() then exec(). I wish to use fork() to support replicated processes, starting with a complete copy of the application's state greatly simplifies this.

Runtime should free methods when profilers are attached

mono_free_method currently does nothing if a profiler is attached. This is because of a bunch of hacks in the log profiler that result in keeping MonoMethod pointers around potentially for longer than their actual lifetime. The thread-local method list is one such hack.

We should investigate whether this can be fixed. One possible fix is to increase the ref count on the MonoImage associated with the MonoMethod while we're keeping these pointers around.

Graphics.FillRegion produces an incorrect result in excluded area

Steps to Reproduce

using System.Drawing;
using System.Drawing.Drawing2D;

namespace graphicstest
{
  class MainClass
  {
    public static void Main(string[] args)
    {
      var image = new Bitmap(400, 400);

      using (var graphics = Graphics.FromImage(image))
      {
        graphics.Clear(Color.Gray);

        var rectPath = new GraphicsPath();
        rectPath.AddRectangle(new Rectangle(50, 50, 300, 300));
        var polyPath = new GraphicsPath();
        polyPath.AddPolygon(new Point[] { new Point(100, 100)
                                        , new Point(200,  75)
                                        , new Point(300, 100)
                                        , new Point(325, 200)
                                        , new Point(300, 300)
                                        , new Point(200, 325)
                                        , new Point(100, 300)
                                        , new Point( 75, 200) });

        var region = new Region();
        region.MakeEmpty();
        region.Union(rectPath);
        region.Exclude(polyPath);

        var brush = new SolidBrush(Color.Lime);
        //var brush = new HatchBrush(HatchStyle.DiagonalCross,
        //                           Color.FromArgb(0x30, Color.White),
        //                           Color.Transparent);
        graphics.FillRegion(brush, region);
      }

      image.Save("test-image.png");
    }
  }
}

Current Behavior

Fills the excluded area with some brighter color.
produced

Expected Behavior

Should not fill the excluded area at all.
expected

Version Used:

In C/C++ (via GDI+ Flat API):
libgdiplus 5.6 (built from sources with prerequisites from the official Ubuntu 16.04 repository)

In C#:
MonoDevelop
Version 7.1 Preview (7.1 build 1291)
Installation UUID: 04a4b1cc-4f29-44d8-93a0-9553c98dd681
Runtime:
Mono 5.2.0 ((HEAD/da80840 Sat Aug 12 16:24:35 UTC 2017) (64-bit)
GTK+ 2.24.29 (Ambiance theme)

Graduate Mono.Profiler.Log to stable status

What needs to happen:

  • Refine and stabilize the API.
  • Remove the library from MONO_API_ASSEMBLIES_IGNORED.
  • Include the library in the mobile and xammac_4_5 profiles (possibly others).
  • Start shipping the library in XA/XI/XM.

Investigate using Ward annotations in the log profiler

It would be nice to try and use Ward annotations to catch violations of various invariants in the log profiler.

A few examples:

  • We shouldn't try to write an event to a log buffer without holding the reader or exclusive lock.
  • We shouldn't start writing a new event to a log buffer if we're already writing one.
  • We shouldn't try to iterate the thread list without holding the exclusive lock.
  • We shouldn't try to acquire the reader or exclusive lock recursively.
  • We shouldn't use signal-unsafe functions in the sample hit callback.

Nonsensical profiler stress test assertion (possible stack corruption)

Control intervals under which performance counters are gathered

LogProfiler should provide API for fine-grained measurement of performance counters. Rather than reporting them every 1s, I would like 2 methods:

  • GetPerformanceCounters - grab all perf counters collected until now
  • ResetPerformanceCounters - reset all counters to 0.

Add some basic coverage profiler tests

While we do exercise the coverage profiler on the BCL on Jenkins, it would be nice to have some tests that actually verify the correctness of the output.

Memory leak when marshalling Delegate to native code

In our project we send callback delegate to native code and found a memory leak at runtime.
This is a sample project that reproduce the problem.

{
   [UnmanagedFunctionPointer( CallingConvention.Cdecl )]
   internal delegate void NativeFunctionCallback(int arg);

   [DllImport("libnative", CallingConvention = CallingConvention.Cdecl)]
   internal static extern void native_function(int arg, NativeFunctionCallback cb);

   private NativeFunctionCallback _cb;

   public CallbackOwner()
   {
      _cb = CallbackImplementation;
   }

   public void Run(int n)
   {
      native_function( n, _cb ); // Expecting leak here!
   }

   private void CallbackImplementation( int arg )
   {
      Console.WriteLine( arg );
   }
}

And write some loop to test

int n = 0;
while ( true )
{
   new CallbackOwner().Run( ++n );

   // Collect managed memory.
   if (n%1000 == 0)
      GC.Collect();
}

"libnative" is a simple test programm that only execute callback.

Full test project added to attachement.
This leak reproduced on Mac and Linux on Windows all fine. With mono-boehm leak not reproduced, only with SGen.

Profiler show memory leak at:

Leak: 0x7f81e74001c0 size=16 zone: DefaultMallocZone_0x1068f1000
0x03b0600e 0x00000000 0x00000000 0x00000000 .`..............
Call stack: [thread 0x7fffb321e340]: | start | main | mono_main | mono_jit_exec | do_exec_main_checked | do_runtime_invoke | mono_jit_runtime_invoke | 0x106a0d427 | mono_delegate_to_ftnptr | mono_jit_compile_method_with_opt | mono_jit_compile_method_inner | mini_method_compile | mono_save_seq_point_info | mono_seq_point_info_new | monoeg_malloc0 | calloc | malloc_zone_calloc

We really like the Mono project and enjoy using it on our servers, but because of the leaks we have to restart the server every 24 hours.

Please help us :)

leaks_mono-sgen.zip
MonoPInvokeLeak2.zip

Creating a new instance of X.509 certificate out of another, empty instance of X.509 certificate must not throw

Steps to Reproduce

Execute the following line of code:

new X509Certificate2(new X509Certificate2());

Current Behavior

An exception is being thrown - System.Security.Cryptography.CryptographicException : Certificate instance is empty.

Expected Behavior

In .NET Framework, this line of code doesn't throw. Mono must behave the same way.

On which platforms did you notice this

Linux (Ubuntu 17.10, 64-bit).

Version Used:

This issue exists in both the latest stable Mono (5.4.1.6) and the latest master branch.

Stacktrace

System.Security.Cryptography.CryptographicException : Certificate instance is empty.
  at System.Security.Cryptography.X509Certificates.X509Helper.ThrowIfContextInvalid (System.Security.Cryptography.X509Certificates.X509CertificateImpl impl) [0x0000e] in /mono/mcs/class/corlib/System.Security.Cryptography.X509Certificates/X509Helper.cs:161 
  at System.Security.Cryptography.X509Certificates.X509Certificate.get_Impl () [0x00000] in /mono/mcs/class/corlib/System.Security.Cryptography.X509Certificates/X509Certificate.cs:137 
  at Mono.Btls.MonoBtlsProvider.GetNativeCertificate (System.Security.Cryptography.X509Certificates.X509Certificate certificate) [0x00000] in /mono/mcs/class/System/Mono.Btls/MonoBtlsProvider.cs:116 
  at System.Security.Cryptography.X509Certificates.X509Helper2.Import (System.Security.Cryptography.X509Certificates.X509Certificate cert, System.Boolean disableProvider) [0x00011] in /mono/mcs/class/System/System.Security.Cryptography.X509Certificates/X509Helper2.cs:149 
  at System.Security.Cryptography.X509Certificates.X509Certificate2..ctor (System.Security.Cryptography.X509Certificates.X509Certificate certificate) [0x0000b] in /mono/mcs/class/System/System.Security.Cryptography.X509Certificates/X509Certificate2.cs:134

Potential bug in HttpContext.RewritePath

I have created my own URL rewriting logic, by making sure I invoke HttpContext.Current.ReWritepath("~/Default.aspx", true) in my Global.asax.cs inside of Application_BeginRequest. This should map all requests to a single page, my Default.aspx that is.

The problem comes later during the setting of my ASP.NET_SessionId cookie, and also the resolving of my WebResouce.axd files, but only if my first HTTP request goes towards a double nested folder inside of my webapp. E.g. /foo/bar.

If I access my webapp with my first request being /, the resolving of my cookie paths and WebResource.axd inclusions are correctly mapped, and they go towards path=/ and /WebResource.axd?xxx.

Notice, the really weird thing, is that if I access my site first with e.g. /, then all later cookie paths and WebResource inclusions, also in a double folder becomes correct ... :P

If I however create my first HTTP request towards e.g. /foo/bar, then my WebResource.axd inclusion tries to include my inclusion as /foo/WebResource.axd?xxx, and my ASP.NET_SessionId cookie path becomes /foo, which of course is not correct ...

I have tried to look at the source code for HttpRequest and HttpContext, to try to determine what they do, and where the bug could be, without success. However, I suspect it is related to the setting of _clientBaseDir within HttpRequest. InternalRewritePath, which I assume is later referenced during inclusion of scripts, and the setting of the path for the session cookie, etc ...

For the record, I have tried tons of different variations, including HttpContext.Current.ReWritepath("~/Default.aspx", false), and many others. And I am pretty confident in that this is somehow a bug in Mono ...

I am going to attempt to use reflection to physically change the internal state of some of your hidden fields, to try to find out more about this, but obviously it's important I believe that a more permanent fix is somehow provided ...

Please advice :)

Thomas

mkbundle Linux - program doesn't run on system unless `mono-core` is installed

Bugzilla ticket:
https://bugzilla.xamarin.com/show_bug.cgi?id=60753#bug_status_bottom

Some more info on Stackoverflow: https://stackoverflow.com/questions/47384100/c-sharp-application-built-with-mkbundle-doesnt-work

Basically I cannot launch a c# app built and bundled using mkbundle unless mono-core is installed.

I run mkbundle --simple --static --deps -o ./SpFetcher bin/Release/SpPrefetchIndexBuilder.exe

But I get this as a result:


    The URI prefix is not recognized.
          at System.Net.WebRequest.Create (System.Uri requestUri, System.Boolean useUriBase) [0x000ae] in <50d80b08c1a5449282b22aedf03ce925>:0 
          at System.Net.WebRequest.Create (System.String requestUriString) [0x00014] in <50d80b08c1a5449282b22aedf03ce925>:0 
          at Microsoft.SharePoint.Client.SPWebRequestExecutor..ctor (Microsoft.SharePoint.Client.ClientRuntimeContext context, System.String requestUrl) [0x0002e] in <c0e6dcb0d2c7447bb9d4f89eec39d654>:0 
          at Microsoft.SharePoint.Client.DefaultWebRequestExecutorFactory.CreateWebRequestExecutor (Microsoft.SharePoint.Client.ClientRuntimeContext context, System.String requestUrl) [0x00021] in <c0e6dcb0d2c7447bb9d4f89eec39d654>:0 
          at Microsoft.SharePoint.Client.ClientContext.GetFormDigestInfoPrivate () [0x0000d] in <e2eb771f808b400bbe60d58b69acf7f0>:0 
          at Microsoft.SharePoint.Client.ClientContext.EnsureFormDigest () [0x0001f] in <e2eb771f808b400bbe60d58b69acf7f0>:0 
          at Microsoft.SharePoint.Client.ClientContext.ExecuteQuery () [0x00008] in <e2eb771f808b400bbe60d58b69acf7f0>:0 
          at SpPrefetchIndexBuilder.SpPrefetchIndexBuilder.getSubWebs (System.String url, System.Collections.Generic.Dictionary`2[TKey,TValue] parentWebDict) [0x00266] in <8afd075a89d9457b827aef736e8e1c09>:0 
          at SpPrefetchIndexBuilder.SpPrefetchIndexBuilder.Main (System.String[] args) [0x00018] in <8afd075a89d9457b827aef736e8e1c09>:0 

This is an unexpected error that doesn't happen when running on Windows in normal circumstances, and it doesn't happen when you run it on a machine with mono-core installed. Why is this error happening does anyone know?

System.Reflection.Emit: PropertyBuilder with generic type doesn't add generic parameter

I've got an issue with Mono when I generate IL with Reflection.Emit. I'm trying to do something similar to this:

class Foo<T>
{
    public T value { get; }
}

with following code:

public static void CreateProperty()
{
    AssemblyName assemblyName = new AssemblyName("FooProperties");
    AssemblyBuilder assemblyBuilder = AppDomain.CurrentDomain.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Save);
    ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule(assemblyName.Name, assemblyName.Name + ".dll");

    TypeBuilder fooTypeBuilder = moduleBuilder.DefineType("Foo", TypeAttributes.Public);
    GenericTypeParameterBuilder[] genericTypes = fooTypeBuilder.DefineGenericParameters("T");
    const string propertyName = "Length";
    // Type propertyType = typeof(int);
    CreateProperty(fooTypeBuilder, propertyName, genericTypes[0]);

    fooTypeBuilder.CreateType();
    assemblyBuilder.Save(assemblyName.Name + ".dll", PortableExecutableKinds.Required32Bit, ImageFileMachine.I386);
}

private static void CreateProperty(TypeBuilder fooTypeBuilder, string propertyName, Type propertyType)
{
    PropertyBuilder propertyBuilder = fooTypeBuilder.DefineProperty(propertyName, PropertyAttributes.None, propertyType, null);            
    propertyBuilder.SetCustomAttribute(CreateCompilerGeneratedAttribute());

    FieldBuilder fieldBuilder = fooTypeBuilder.DefineField(GetBackingFieldName(propertyName), propertyType, FieldAttributes.Private);
    fieldBuilder.SetCustomAttribute(CreateCompilerGeneratedAttribute());

    MethodBuilder getPropertyMethodBuilder = CreateGetter(fooTypeBuilder, propertyName, propertyType, fieldBuilder);
    MethodBuilder setPropertyMethodBuilder = CreateSetter(fooTypeBuilder, propertyName, propertyType, fieldBuilder);

    propertyBuilder.SetGetMethod(getPropertyMethodBuilder);
    propertyBuilder.SetSetMethod(setPropertyMethodBuilder);
}

private static MethodBuilder CreateSetter(TypeBuilder fooTypeBuilder, string propertyName, Type propertyType, FieldBuilder fieldBuilder)
{
    MethodBuilder setPropertyMethodBuilder = fooTypeBuilder.DefineMethod(GetSetterAccessorName(propertyName),
        MethodAttributes.SpecialName | MethodAttributes.Public | MethodAttributes.HideBySig,
        typeof(void), new[] {propertyType});
    ILGenerator setterBody = setPropertyMethodBuilder.GetILGenerator();
    setterBody.Emit(Ldarg_0);
    setterBody.Emit(Ldarg_1);
    setterBody.Emit(Stfld, fieldBuilder);
    setterBody.Emit(Ret);
    setPropertyMethodBuilder.SetCustomAttribute(CreateCompilerGeneratedAttribute());
    return setPropertyMethodBuilder;
}

private static MethodBuilder CreateGetter(TypeBuilder fooTypeBuilder, string propertyName, Type propertyType, FieldBuilder fieldBuilder)
{
    MethodBuilder getPropertyMethodBuilder = fooTypeBuilder.DefineMethod(GetGetterAccessorName(propertyName),
        MethodAttributes.SpecialName | MethodAttributes.Public | MethodAttributes.HideBySig, propertyType, Type.EmptyTypes);
    ILGenerator getterBody = getPropertyMethodBuilder.GetILGenerator();
    getterBody.Emit(Ldarg_0);
    getterBody.Emit(Ldfld, fieldBuilder);
    getterBody.Emit(Ret);
    getPropertyMethodBuilder.SetCustomAttribute(CreateCompilerGeneratedAttribute());
    return getPropertyMethodBuilder;
}

private static CustomAttributeBuilder CreateCompilerGeneratedAttribute()
{
    var compilerGeneratedAttributeCtor = typeof(CompilerGeneratedAttribute).GetConstructor(new Type[0]);
    Debug.Assert(compilerGeneratedAttributeCtor != null, "compilerGeneratedAttributeCtor != null");
    return new CustomAttributeBuilder(compilerGeneratedAttributeCtor, new object[0]);
}

private static string GetBackingFieldName(string propertyName) => $"<{propertyName}>_BackingField";

private static string GetSetterAccessorName(string propertyName) => $"set_{propertyName}";

private static string GetGetterAccessorName(string propertyName) => $"get_{propertyName}";

However when assembly looks like this:

IL_0000:  ldarg.0
IL_0001:  ldfld !0 Foo::'<Length>_BackingField'
IL_0006:  ret

As you see Foo type is wrong, it doesn't carry generic parameter (should be class Foo<!0>::). When I dump C# equivalent I get this:

IL_0000:  ldarg.0
IL_0001:  ldfld !0 class CodeGenSnippets.MyFoo`1<!0>::'<value>k__BackingField'
IL_0006:  ret

Btw, on Windows, with Microsoft's Reflection.Emit it works fine.

Mono JIT compiler version 5.4.1.6 (2017-06/1f4613aa1ac Wed Oct 18 09:31:57 EDT 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: normal
SIGSEGV: altstack
Notification: kqueue
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: yes(3.6.0svn-mono-master/8b1520c8aae)
GC: sgen (concurrent by default)

C# compiler reports CS1540 on protected non-function member access even when there is a matching hidden public member in a base class

With the following class structure, mcs (tested on Windows 5.4.1.0) fails with error CS1540 "Cannot access protected member `B.Field' via a qualifier of type `B'. The qualifier must be of type `M.C' or derived from it", while VS C# 6.0 compiles and runs successfully. Casting to the base class which declared the public member to access the member avoids the error.

public class A {
	public bool Field;
}

public class B : A {
	protected new bool Field;
}

public class C : B {
	public void Z(B b) {
		// CS1540
		b.Field = true;
	}
}

Complete example at https://gist.github.com/colinjneville/ba7d8ac13c84e135f19df500d1879e20

This doesn't affect methods, which resolve to the public version without error. It's not clear to me whether both should be errors or neither; although VS allows both, from my interpretation of the C# 6.0 draft spec, it does seem like the error is technically correct.

If the declared accessibility of T is public, the accessibility domain of T is the program text of P and any program that references P

The accessibility domain of A, B, C is the entire example.

If the declared accessibility of M is public, the accessibility domain of M is the accessibility domain of T

The accessibility domain of A.Field as also the entire example.

If the declared accessibility of M is protected, let D be the union of the program text of T and the program text of any type derived from T. The accessibility domain of M is the intersection of the accessibility domain of T with D.

The accessibility domain of B.Field is the text of B and C.

The scope of a member declared by a class_member_declaration (Class body) is the class_body in which the declaration occurs. In addition, the scope of a class member extends to the class_body of those derived classes that are included in the accessibility domain (Accessibility domains) of the member.

The scope of A.Field is A, B, and C, and the scope of B.Field is B and C.

A constant, field, property, event, or type introduced in a class or struct hides all base class members with the same name.
A method introduced in a class or struct hides all non-method base class members with the same name, and all base class methods with the same signature (method name and parameter count, modifiers, and types).
A declaration of a new member hides an inherited member only within the scope of the new member.

C is in the scope of B.Field, so B.Field should hide A.Field in C.

When a protected instance member is accessed outside the program text of the class in which it is declared, ... the access must take place within a class declaration that derives from the class in which it is declared. Furthermore, the access is required to take place through an instance of that derived class type or a class type constructed from it. This restriction prevents one derived class from accessing protected members of other derived classes, even when the members are inherited from the same base class.

This clause prevents access to B.Field with a B instance from C, but does not prevent hiding.

Thread objects are being leaked

Starting a bg thread with new Thread() and starting it with either a parameter or not causes the code to leak the start method (and, if applicable, the start arguments).

The retention path for the parametrized start is GCHandle -> InternalThread -> Thread -> ParametrizedThreadStart -> ThreadHelper -> <thread start parameter object> .

The threads are definitely collectible and leaking, as Thread.Join() successfully passes.

Consolidate the concept of a tools thread and a thread that has opted out of STW

Right now, we have two ways of opting out of participating in STW:

  • Attach as a tools thread (call mono_threads_attach_tools_thread).
  • Attach normally and opt out (call mono_gc_set_skip_thread).

I believe that it would be completely fine for us to consolidate these two. Currently, a tools thread is basically just a thread that's attached through the MonoThreadInfo infrastructure only (i.e. it has no MonoInternalThread set, no domain, etc). Only the profiler uses tools threads. In reality, all the profiler needs is that tools threads do not participate in STW and are not considered for statistical sampling - nothing else. Having a MonoInternalThread and a domain set for these threads is not a problem at all.

In fact, not having a domain set for tools threads is proving to be a problem. The tools threads in the profiler sometimes call into runtime functions that end up wanting to use mono_domain_get, thus crashing since no domain is set. For example, using the log profiler with an AOT-compiled Roslyn results in this crash:

	0   mono                                0x0000000101a5fd91 mono_handle_native_crash + 257
	1   mono                                0x00000001019b334c mono_sigsegv_signal_handler + 220
	2   libsystem_platform.dylib            0x00007fffcf037b3a _sigtramp + 26
	3   ???                                 0x00007fb1cd479810 0x0 + 140401629960208
	4   mono                                0x0000000101ae61e7 mono_assembly_load_full_nosearch + 439
	5   mono                                0x0000000101ae22a8 mono_assembly_load_full_internal + 40
	6   mono                                0x0000000101ae1f17 mono_assembly_load_reference + 519
	7   mono                                0x0000000101ae8c5d mono_class_from_typeref_checked + 573
	8   mono                                0x0000000101af767d mono_class_get_checked + 173
	9   mono                                0x0000000101b4ac16 mono_metadata_parse_type_internal + 1238
	10  mono                                0x0000000101b4b5ee mono_metadata_parse_method_signature_full + 590
	11  mono                                0x0000000101b25aa3 mono_method_signature_checked + 483
	12  mono                                0x0000000101b05c46 mono_method_get_name_full + 726
	13  libmono-profiler-log.0.dylib        0x0000000101ecaf3d handle_writer_queue_entry + 205
	14  libmono-profiler-log.0.dylib        0x0000000101ecad98 writer_thread + 568
	15  libsystem_pthread.dylib             0x00007fffcf04193b _pthread_body + 180
	16  libsystem_pthread.dylib             0x00007fffcf041887 _pthread_body + 0
	17  libsystem_pthread.dylib             0x00007fffcf04108d thread_start + 13

So, my plan to fix this is as follows:

  • Remove the whole tools thread concept.
  • Remove mono_gc_set_skip_thread (it's not public API).
  • Move the gc_disabled field to MonoThreadInfo.
  • Introduce mono_thread_info_set_skip_suspend (replaces mono_gc_set_skip_thread) and mono_thread_info_set_skip_sample.
  • Attach profiler background threads normally (possibly even start them using mono_thread_create_internal).
  • Use the new functions to make the runtime skip STW and sampling on profiler background threads.
  • Make the rest of the runtime check these bits where needed.

Originally filed at: https://bugzilla.xamarin.com/show_bug.cgi?id=59024

AllocationEvent's come before associated VTable event

In mono master (5.11), the MLPDs produced by the runtime profiler seem to have one problem, only happening for a few "System.RuntimeType" allocations that seem to happen at the beginning of the application. The series of events is:

(Messages obtained via adding debugging console output to Xamarin.Profiler on a v15 MLPD where the problem was seen)
Buffer ID's are the buffer's TimeBase field, and the 2nd number is the timestamp of the specific event:

  1. ClassLoad event:
    The culprit is System.RuntimeType at buffer 19250786083136 at 19250788456173
  2. Several Allocation events for objects of that type, without any stack trace:
    No backtrace at buffer 19250786083136 at 19250789353288
    No backtrace at buffer 19250786083136 at 19250789359463
    No backtrace at buffer 19250786083136 at 19250789362233
    No backtrace at buffer 19250786083136 at 19250789363302
    No backtrace at buffer 19250786083136 at 19250789364130
  3. VTable event for the unknown-till-now VTablePointer:
    Got unknown VTable for class 2072191896 at buffer 19250786083136 at 19250789365557

All events are in the same buffer, and it is not an ordering problem because of the timestamp sorting in SyncPoint, as the events have different timestamps

Rewrite versions.py as a C# script

During make (using patch that fixes #6197), mono is not liking when system's default python is python3 (the python executable in path refers to python3 on some distros nowadays)--try checking for python2 (maybe with if file exists $(command -v python2) or checking whether python2 exists in path or something), before using python binary directly which would result in this:

make[2]: Entering directory '/home/owner/GitHub/mono/acceptance-tests'
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
  File "versions.py", line 11
    print "Not found"
                    ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "Not found")?
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/owner/GitHub/mono/acceptance-tests'
make[2]: Entering directory '/home/owner/GitHub/mono'
make[2]: Leaving directory '/home/owner/GitHub/mono'
make[1]: Leaving directory '/home/owner/GitHub/mono'

if you need to make the change in shell script manually such as autogen.sh you may want to add something like:

this_python=python
this_python2=$(command -v python2)
if [ -f "$this_python2" ]; then
  #if you don't put quotes around $this_python in the line above, blank will return true due to wierd bash behavior
  this_python=$this_python2
fi

where this_python is the actual environment variable that could somehow be used later where it is currently assumed to be path's python

Switch to Mach thread suspend API for sampling

Signal delivery on OS X is not very reliable. There are no real time signals nor signal queuing of any kind. This means that in programs with lots of threads, we lose tons of samples. To make matters worse, most sample signals tend to be delivered to one particular thread, while all other threads barely get any samples.

To solve this problem, the sampling background thread should instead use the Mach thread suspend APIs to suspend a thread, grab its machine context, perform the sample hit callback (where we collect a backtrace, send it to the dumper thread, etc), then resume the thread. Since the thread suspend APIs use a counter internally, this should not interfere with our STW machinery.

We will need to introduce a new sample hit callback in the profiler API since the current one is guaranteed to be invoked from a signal handler on the sampled thread.

Relevant Mach APIs:

during make Got a SIGABRT while executing native code (using get-monolite-latest)

OS: recently updated Antergos
As per README.md I did:

#not the mono-project.com way:
#PREFIX=/usr/local
#./autogen.sh --prefix=$PREFIX
#./configure --prefix=$PREFIX
#but the README.md way:
./autogen.sh
make get-monolite-latest
make

but at some point during compile I get:

make[2]: Entering directory '/home/owner/GitHub/mono/runtime'
if test -w /home/owner/GitHub/mono/mcs; then :; else chmod -R +w /home/owner/GitHub/mono/mcs; fi
cd /home/owner/GitHub/mono/mcs && make --no-print-directory -s NO_DIR_CHECK=1 PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14           ' CC='gcc' all-profiles
make[6]: mono: Command not found
make[6]: *** [build/profiles/basic.make:116: build/deps/basic-profile-check.exe] Error 127
*** The runtime 'mono' doesn't appear to be usable.
*** Trying the 'monolite-linux/1051100001' directory.
Instruction metadata for iconst inconsistent.
Instruction metadata for i8const inconsistent.
Instruction metadata for r4const inconsistent.
Instruction metadata for r8const inconsistent.
Instruction metadata for dummy_iconst inconsistent.
Instruction metadata for dummy_r8const inconsistent.
Instruction metadata for throw inconsistent.
Instruction metadata for rethrow inconsistent.
Instruction metadata for oparglist inconsistent.
Instruction metadata for store_membase_reg inconsistent.
Instruction metadata for storei1_membase_reg inconsistent.
Instruction metadata for storei2_membase_reg inconsistent.
Instruction metadata for storei4_membase_reg inconsistent.
Instruction metadata for storei8_membase_reg inconsistent.
Instruction metadata for storer4_membase_reg inconsistent.
Instruction metadata for storer8_membase_reg inconsistent.
Instruction metadata for storex_membase_reg inconsistent.
Instruction metadata for storex_aligned_membase_reg inconsistent.
Instruction metadata for storex_nta_membase_reg inconsistent.
Instruction metadata for store_membase_imm inconsistent.
Instruction metadata for storei1_membase_imm inconsistent.
Instruction metadata for storei2_membase_imm inconsistent.
Instruction metadata for storei4_membase_imm inconsistent.
Instruction metadata for storei8_membase_imm inconsistent.
Instruction metadata for storex_membase inconsistent.
Instruction metadata for load_membase inconsistent.
Instruction metadata for loadi1_membase inconsistent.
Instruction metadata for loadu1_membase inconsistent.
Instruction metadata for loadi2_membase inconsistent.
Instruction metadata for loadu2_membase inconsistent.
Instruction metadata for loadi4_membase inconsistent.
Instruction metadata for loadu4_membase inconsistent.
Instruction metadata for loadi8_membase inconsistent.
Instruction metadata for loadr4_membase inconsistent.
Instruction metadata for loadr8_membase inconsistent.
Instruction metadata for loadx_membase inconsistent.
Instruction metadata for loadx_aligned_membase inconsistent.
Instruction metadata for load_mem inconsistent.
Instruction metadata for loadu1_mem inconsistent.
Instruction metadata for loadu2_mem inconsistent.
Instruction metadata for loadi4_mem inconsistent.
Instruction metadata for loadu4_mem inconsistent.
Instruction metadata for loadi8_mem inconsistent.
Instruction metadata for move inconsistent.
Instruction metadata for fmove inconsistent.
Instruction metadata for rmove inconsistent.
Instruction metadata for move_f_to_i4 inconsistent.
Instruction metadata for move_i4_to_f inconsistent.
Instruction metadata for move_f_to_i8 inconsistent.
Instruction metadata for move_i8_to_f inconsistent.
Instruction metadata for add_imm inconsistent.
Instruction metadata for sub_imm inconsistent.
Instruction metadata for mul_imm inconsistent.
Instruction metadata for and_imm inconsistent.
Instruction metadata for or_imm inconsistent.
Instruction metadata for xor_imm inconsistent.
Instruction metadata for shl_imm inconsistent.
Instruction metadata for shr_imm inconsistent.
Instruction metadata for shr_un_imm inconsistent.
Instruction metadata for br inconsistent.
Instruction metadata for break inconsistent.
Instruction metadata for ceq inconsistent.
Instruction metadata for cgt inconsistent.
Instruction metadata for cgt.un inconsistent.
Instruction metadata for clt inconsistent.
Instruction metadata for clt.un inconsistent.
Instruction metadata for long_neg inconsistent.
Instruction metadata for long_not inconsistent.
Instruction metadata for long_conv_to_i1 inconsistent.
Instruction metadata for long_conv_to_i2 inconsistent.
Instruction metadata for long_conv_to_i4 inconsistent.
Instruction metadata for long_conv_to_i8 inconsistent.
Instruction metadata for long_conv_to_r4 inconsistent.
Instruction metadata for long_conv_to_r8 inconsistent.
Instruction metadata for long_conv_to_u4 inconsistent.
Instruction metadata for long_conv_to_u8 inconsistent.
Instruction metadata for long_conv_to_u2 inconsistent.
Instruction metadata for long_conv_to_u1 inconsistent.
Instruction metadata for long_conv_to_ovf_i4_un inconsistent.
Instruction metadata for long_conv_to_ovf_u4 inconsistent.
Instruction metadata for long_ceq inconsistent.
Instruction metadata for long_cgt inconsistent.
Instruction metadata for long_cgt_un inconsistent.
Instruction metadata for long_clt inconsistent.
Instruction metadata for long_clt_un inconsistent.
Instruction metadata for long_conv_to_r_un inconsistent.
Instruction metadata for long_add_imm inconsistent.
Instruction metadata for long_sub_imm inconsistent.
Instruction metadata for long_mul_imm inconsistent.
Instruction metadata for long_and_imm inconsistent.
Instruction metadata for long_or_imm inconsistent.
Instruction metadata for long_xor_imm inconsistent.
Instruction metadata for long_shl_imm inconsistent.
Instruction metadata for long_shr_imm inconsistent.
Instruction metadata for long_shr_un_imm inconsistent.
Instruction metadata for long_beq inconsistent.
Instruction metadata for int_neg inconsistent.
Instruction metadata for int_not inconsistent.
Instruction metadata for int_conv_to_i1 inconsistent.
Instruction metadata for int_conv_to_i2 inconsistent.
Instruction metadata for int_conv_to_i4 inconsistent.
Instruction metadata for int_conv_to_i8 inconsistent.
Instruction metadata for int_conv_to_r4 inconsistent.
Instruction metadata for int_conv_to_r8 inconsistent.
Instruction metadata for int_conv_to_u4 inconsistent.
Instruction metadata for int_conv_to_u8 inconsistent.
Instruction metadata for int_conv_to_u inconsistent.
Instruction metadata for int_conv_to_u2 inconsistent.
Instruction metadata for int_conv_to_u1 inconsistent.
Instruction metadata for int_conv_to_i inconsistent.
Instruction metadata for int_adc_imm inconsistent.
Instruction metadata for int_sbb_imm inconsistent.
Instruction metadata for int_add_imm inconsistent.
Instruction metadata for int_sub_imm inconsistent.
Instruction metadata for int_mul_imm inconsistent.
Instruction metadata for int_div_imm inconsistent.
Instruction metadata for int_div_un_imm inconsistent.
Instruction metadata for int_rem_un_imm inconsistent.
Instruction metadata for int_and_imm inconsistent.
Instruction metadata for int_or_imm inconsistent.
Instruction metadata for int_xor_imm inconsistent.
Instruction metadata for int_shl_imm inconsistent.
Instruction metadata for int_shr_imm inconsistent.
Instruction metadata for int_shr_un_imm inconsistent.
Instruction metadata for int_ceq inconsistent.
Instruction metadata for int_cgt inconsistent.
Instruction metadata for int_cgt_un inconsistent.
Instruction metadata for int_clt inconsistent.
Instruction metadata for int_clt_un inconsistent.
Instruction metadata for int_cneq inconsistent.
Instruction metadata for int_cge inconsistent.
Instruction metadata for int_cle inconsistent.
Instruction metadata for int_cge_un inconsistent.
Instruction metadata for int_cle_un inconsistent.
Instruction metadata for float_neg inconsistent.
Instruction metadata for float_not inconsistent.
Instruction metadata for float_conv_to_i1 inconsistent.
Instruction metadata for float_conv_to_i2 inconsistent.
Instruction metadata for float_conv_to_i4 inconsistent.
Instruction metadata for float_conv_to_i8 inconsistent.
Instruction metadata for float_conv_to_r4 inconsistent.
Instruction metadata for float_conv_to_u4 inconsistent.
Instruction metadata for float_conv_to_u8 inconsistent.
Instruction metadata for r4_neg inconsistent.
Instruction metadata for r4_conv_to_i1 inconsistent.
Instruction metadata for r4_conv_to_i2 inconsistent.
Instruction metadata for r4_conv_to_i4 inconsistent.
Instruction metadata for r4_conv_to_i8 inconsistent.
Instruction metadata for r4_conv_to_r4 inconsistent.
Instruction metadata for r4_conv_to_r8 inconsistent.
Instruction metadata for r4_conv_to_u4 inconsistent.
Instruction metadata for float_conv_to_u2 inconsistent.
Instruction metadata for float_conv_to_u1 inconsistent.
Instruction metadata for float_conv_to_i inconsistent.
Instruction metadata for float_conv_to_ovf_i inconsistent.
Instruction metadata for float_conv_to_ovd_u inconsistent.
Instruction metadata for float_conv_to_u inconsistent.
Instruction metadata for ckfinite inconsistent.
Instruction metadata for r4_conv_to_u2 inconsistent.
Instruction metadata for r4_conv_to_u1 inconsistent.
Instruction metadata for jump_table inconsistent.
Instruction metadata for aot_const inconsistent.
Instruction metadata for start_handler inconsistent.
Instruction metadata for endfilter inconsistent.
Instruction metadata for get_ex_obj inconsistent.
Instruction metadata for adc_imm inconsistent.
Instruction metadata for sbb_imm inconsistent.
Instruction metadata for br_reg inconsistent.
Instruction metadata for br_reg inconsistent.
Instruction metadata for sext_i1 inconsistent.
Instruction metadata for sext_i2 inconsistent.
Instruction metadata for sext_i4 inconsistent.
Instruction metadata for zext_i4 inconsistent.
Instruction metadata for sin inconsistent.
Instruction metadata for cos inconsistent.
Instruction metadata for abs inconsistent.
Instruction metadata for tan inconsistent.
Instruction metadata for atan inconsistent.
Instruction metadata for sqrt inconsistent.
Instruction metadata for tls_get inconsistent.
Instruction metadata for tls_set inconsistent.
Instruction metadata for dummy_use inconsistent.
Instruction metadata for not_null inconsistent.
Instruction metadata for dupps_low inconsistent.
Instruction metadata for dupps_high inconsistent.
Instruction metadata for rsqrtps inconsistent.
Instruction metadata for sqrtps inconsistent.
Instruction metadata for rcpps inconsistent.
Instruction metadata for pshufflew_high inconsistent.
Instruction metadata for pshufflew_low inconsistent.
Instruction metadata for pshuffled inconsistent.
Instruction metadata for duppd inconsistent.
Instruction metadata for sqrtpd inconsistent.
Instruction metadata for extract_mask inconsistent.
Instruction metadata for pshrw inconsistent.
Instruction metadata for psarw inconsistent.
Instruction metadata for pshlw inconsistent.
Instruction metadata for pshrd inconsistent.
Instruction metadata for pshrq inconsistent.
Instruction metadata for psard inconsistent.
Instruction metadata for pshld inconsistent.
Instruction metadata for pshlq inconsistent.
Instruction metadata for extract_i4 inconsistent.
Instruction metadata for iconv_to_r4_raw inconsistent.
Instruction metadata for extract_i2 inconsistent.
Instruction metadata for extract_u2 inconsistent.
Instruction metadata for extract_i1 inconsistent.
Instruction metadata for extract_u1 inconsistent.
Instruction metadata for extract_r8 inconsistent.
Instruction metadata for extract_i8 inconsistent.
Instruction metadata for extractx_u2 inconsistent.
Instruction metadata for fconv_to_r8_x inconsistent.
Instruction metadata for xconv_r8_to_i4 inconsistent.
Instruction metadata for iconv_to_x inconsistent.
Instruction metadata for expand_i2 inconsistent.
Instruction metadata for expand_i4 inconsistent.
Instruction metadata for expand_r4 inconsistent.
Instruction metadata for expand_i8 inconsistent.
Instruction metadata for expand_r8 inconsistent.
Instruction metadata for prefetch_membase inconsistent.
Instruction metadata for cvtdq2pd inconsistent.
Instruction metadata for cvtdq2ps inconsistent.
Instruction metadata for cvtpd2dq inconsistent.
Instruction metadata for cvtpd2ps inconsistent.
Instruction metadata for cvtps2dq inconsistent.
Instruction metadata for cvtps2pd inconsistent.
Instruction metadata for cvttpd2dq inconsistent.
Instruction metadata for cvttps2dq inconsistent.
Instruction metadata for xmove inconsistent.
Instruction metadata for xzero inconsistent.
Instruction metadata for xones inconsistent.
Instruction metadata for atomic_load_i1 inconsistent.
Instruction metadata for atomic_load_i2 inconsistent.
Instruction metadata for atomic_load_i4 inconsistent.
Instruction metadata for atomic_load_i8 inconsistent.
Instruction metadata for atomic_load_u1 inconsistent.
Instruction metadata for atomic_load_u2 inconsistent.
Instruction metadata for atomic_load_u4 inconsistent.
Instruction metadata for atomic_load_u8 inconsistent.
Instruction metadata for atomic_load_r4 inconsistent.
Instruction metadata for atomic_load_r8 inconsistent.
Instruction metadata for atomic_store_i1 inconsistent.
Instruction metadata for atomic_store_i2 inconsistent.
Instruction metadata for atomic_store_i4 inconsistent.
Instruction metadata for atomic_store_i8 inconsistent.
Instruction metadata for atomic_store_u1 inconsistent.
Instruction metadata for atomic_store_u2 inconsistent.
Instruction metadata for atomic_store_u4 inconsistent.
Instruction metadata for atomic_store_u8 inconsistent.
Instruction metadata for atomic_store_r4 inconsistent.
Instruction metadata for atomic_store_r8 inconsistent.
Instruction metadata for liverange_start inconsistent.
Instruction metadata for gc_safe_point inconsistent.
Instruction metadata for generic_class_init inconsistent.
Instruction metadata for generic_class_init inconsistent.
Instruction metadata for x86_test_null inconsistent.
Instruction metadata for x86_test_null inconsistent.
Instruction metadata for x86_compare_membase_imm inconsistent.
Instruction metadata for x86_compare_membase8_imm inconsistent.
Instruction metadata for x86_inc_reg inconsistent.
Instruction metadata for x86_inc_membase inconsistent.
Instruction metadata for x86_inc_membase inconsistent.
Instruction metadata for x86_dec_reg inconsistent.
Instruction metadata for x86_dec_membase inconsistent.
Instruction metadata for x86_dec_membase inconsistent.
Instruction metadata for x86_add_membase_imm inconsistent.
Instruction metadata for x86_sub_membase_imm inconsistent.
Instruction metadata for x86_and_membase_imm inconsistent.
Instruction metadata for x86_or_membase_imm inconsistent.
Instruction metadata for x86_xor_membase_imm inconsistent.
Instruction metadata for x86_push_membase inconsistent.
Instruction metadata for x86_push_membase inconsistent.
Instruction metadata for x86_push inconsistent.
Instruction metadata for x86_push_obj inconsistent.
Instruction metadata for x86_lea_membase inconsistent.
Instruction metadata for x86_fpop inconsistent.
Instruction metadata for x86_fpop inconsistent.
Instruction metadata for x86_seteq_membase inconsistent.
Instruction metadata for amd64_test_null inconsistent.
Instruction metadata for amd64_set_xmmreg_r4 inconsistent.
Instruction metadata for amd64_set_xmmreg_r8 inconsistent.
Instruction metadata for amd64_icompare_membase_reg inconsistent.
Instruction metadata for amd64_icompare_membase_imm inconsistent.
Instruction metadata for amd64_compare_membase_imm inconsistent.
Instruction metadata for amd64_add_membase_imm inconsistent.
Instruction metadata for amd64_sub_membase_imm inconsistent.
Instruction metadata for amd64_and_membase_imm inconsistent.
Instruction metadata for amd64_or_membase_imm inconsistent.
Instruction metadata for amd64_xor_membase_imm inconsistent.
Instruction metadata for get_last_error inconsistent.
Instruction metadata for fill_prof_call_ctx inconsistent.
wrong maximal instruction length of instruction move (expected 0, got 3)
* Assertion: should not be reached at mini-amd64.c:6503

Stacktrace:

/proc/self/maps:
40045000-40055000 rwxp 00000000 00:00 0 
4046e000-4047e000 rwxp 00000000 00:00 0 
563d5d005000-563d5d414000 r-xp 00000000 fe:00 45617245                   /home/owner/GitHub/mono/mono/mini/mono-sgen
563d5d613000-563d5d61a000 r--p 0040e000 fe:00 45617245                   /home/owner/GitHub/mono/mono/mini/mono-sgen
563d5d61a000-563d5d61e000 rw-p 00415000 fe:00 45617245                   /home/owner/GitHub/mono/mono/mini/mono-sgen
563d5d61e000-563d5d635000 rw-p 00000000 00:00 0 
563d5e528000-563d5e5ad000 rw-p 00000000 00:00 0                          [heap]
7eff78c40000-7eff78fff000 r--p 00000000 fe:00 45878931                   /home/owner/GitHub/mono/mcs/class/lib/monolite-linux/1051100001/mscorlib.dll
7eff78fff000-7eff79fff000 rw-p 00000000 00:00 0 
7eff79fff000-7eff7a000000 ---p 00000000 00:00 0 
7eff7a000000-7eff7ac00000 rw-p 00000000 00:00 0 
7eff7ad57000-7eff7aef2000 r--p 00000000 fe:00 28620940                   /usr/lib/locale/locale-archive
7eff7aef2000-7eff7b0a0000 r-xp 00000000 fe:00 28575996                   /usr/lib/libc-2.26.so
7eff7b0a0000-7eff7b2a0000 ---p 001ae000 fe:00 28575996                   /usr/lib/libc-2.26.so
7eff7b2a0000-7eff7b2a4000 r--p 001ae000 fe:00 28575996                   /usr/lib/libc-2.26.so
7eff7b2a4000-7eff7b2a6000 rw-p 001b2000 fe:00 28575996                   /usr/lib/libc-2.26.so
7eff7b2a6000-7eff7b2aa000 rw-p 00000000 00:00 0 
7eff7b2aa000-7eff7b2c0000 r-xp 00000000 fe:00 28618556                   /usr/lib/libgcc_s.so.1
7eff7b2c0000-7eff7b4bf000 ---p 00016000 fe:00 28618556                   /usr/lib/libgcc_s.so.1
7eff7b4bf000-7eff7b4c0000 r--p 00015000 fe:00 28618556                   /usr/lib/libgcc_s.so.1
7eff7b4c0000-7eff7b4c1000 rw-p 00016000 fe:00 28618556                   /usr/lib/libgcc_s.so.1
7eff7b4c1000-7eff7b4da000 r-xp 00000000 fe:00 28576019                   /usr/lib/libpthread-2.26.so
7eff7b4da000-7eff7b6d9000 ---p 00019000 fe:00 28576019                   /usr/lib/libpthread-2.26.so
7eff7b6d9000-7eff7b6da000 r--p 00018000 fe:00 28576019                   /usr/lib/libpthread-2.26.so
7eff7b6da000-7eff7b6db000 rw-p 00019000 fe:00 28576019                   /usr/lib/libpthread-2.26.so
7eff7b6db000-7eff7b6df000 rw-p 00000000 00:00 0 
7eff7b6df000-7eff7b6e2000 r-xp 00000000 fe:00 28575933                   /usr/lib/libdl-2.26.so
7eff7b6e2000-7eff7b8e1000 ---p 00003000 fe:00 28575933                   /usr/lib/libdl-2.26.so
7eff7b8e1000-7eff7b8e2000 r--p 00002000 fe:00 28575933                   /usr/lib/libdl-2.26.so
7eff7b8e2000-7eff7b8e3000 rw-p 00003000 fe:00 28575933                   /usr/lib/libdl-2.26.so
7eff7b8e3000-7eff7b8ea000 r-xp 00000000 fe:00 28575921                   /usr/lib/librt-2.26.so
7eff7b8ea000-7eff7bae9000 ---p 00007000 fe:00 28575921                   /usr/lib/librt-2.26.so
7eff7bae9000-7eff7baea000 r--p 00006000 fe:00 28575921                   /usr/lib/librt-2.26.so
7eff7baea000-7eff7baeb000 rw-p 00007000 fe:00 28575921                   /usr/lib/librt-2.26.so
7eff7baeb000-7eff7bc36000 r-xp 00000000 fe:00 28575932                   /usr/lib/libm-2.26.so
7eff7bc36000-7eff7be35000 ---p 0014b000 fe:00 28575932                   /usr/lib/libm-2.26.so
7eff7be35000-7eff7be36000 r--p 0014a000 fe:00 28575932                   /usr/lib/libm-2.26.so
7eff7be36000-7eff7be37000 rw-p 0014b000 fe:00 28575932                   /usr/lib/libm-2.26.so
7eff7be37000-7eff7be5c000 r-xp 00000000 fe:00 28575997                   /usr/lib/ld-2.26.so
7eff7bef8000-7eff7bf78000 rw-p 00000000 00:00 0 
7eff7bf79000-7eff7bf7a000 rw-p 00000000 00:00 0 
7eff7bf7a000-7eff7bfd9000 ---p 00000000 00:00 0 
7eff7bfd9000-7eff7bfe0000 rw-p 00000000 00:00 0 
7eff7c00c000-7eff7c010000 rw-p 00000000 00:00 0 
7eff7c011000-7eff7c019000 rw-p 00000000 00:00 0 
7eff7c019000-7eff7c01a000 rw-s 00000000 00:15 914042                     /dev/shm/mono.23384
7eff7c01a000-7eff7c05b000 rw-p 00000000 00:00 0 
7eff7c05b000-7eff7c05c000 r--p 00024000 fe:00 28575997                   /usr/lib/ld-2.26.so
7eff7c05c000-7eff7c05d000 rw-p 00025000 fe:00 28575997                   /usr/lib/ld-2.26.so
7eff7c05d000-7eff7c05e000 rw-p 00000000 00:00 0 
7ffd69846000-7ffd69867000 rw-p 00000000 00:00 0                          [stack]
7ffd699df000-7ffd699e2000 r--p 00000000 00:00 0                          [vvar]
7ffd699e2000-7ffd699e4000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Native stacktrace:

	/home/owner/GitHub/mono/mono/mini/mono(+0xc7a5a) [0x563d5d0cca5a]
	/usr/lib/libpthread.so.0(+0x11da0) [0x7eff7b4d2da0]
	/usr/lib/libc.so.6(gsignal+0x110) [0x7eff7af268a0]
	/usr/lib/libc.so.6(abort+0x1c9) [0x7eff7af27f09]
	/home/owner/GitHub/mono/mono/mini/mono(+0x2d67e0) [0x563d5d2db7e0]
	/home/owner/GitHub/mono/mono/mini/mono(monoeg_g_logv+0x4d) [0x563d5d2f0c5d]
	/home/owner/GitHub/mono/mono/mini/mono(monoeg_assertion_message+0xa3) [0x563d5d2f0df3]
	/home/owner/GitHub/mono/mono/mini/mono(+0x14e10f) [0x563d5d15310f]
	/home/owner/GitHub/mono/mono/mini/mono(+0x162eb5) [0x563d5d167eb5]
	/home/owner/GitHub/mono/mono/mini/mono(+0x164fb3) [0x563d5d169fb3]
	/home/owner/GitHub/mono/mono/mini/mono(+0x165e54) [0x563d5d16ae54]
	/home/owner/GitHub/mono/mono/mini/mono(+0x3f075) [0x563d5d044075]
	/home/owner/GitHub/mono/mono/mini/mono(+0x40235) [0x563d5d045235]
	/home/owner/GitHub/mono/mono/mini/mono(+0x20be55) [0x563d5d210e55]
	/home/owner/GitHub/mono/mono/mini/mono(+0x1b2cb1) [0x563d5d1b7cb1]
	/home/owner/GitHub/mono/mono/mini/mono(+0x185af0) [0x563d5d18aaf0]
	/home/owner/GitHub/mono/mono/mini/mono(+0x187d38) [0x563d5d18cd38]
	/home/owner/GitHub/mono/mono/mini/mono(+0x433da) [0x563d5d0483da]
	/home/owner/GitHub/mono/mono/mini/mono(mono_main+0x414) [0x563d5d0996f4]
	/home/owner/GitHub/mono/mono/mini/mono(+0x3a5f1) [0x563d5d03f5f1]
	/usr/lib/libc.so.6(__libc_start_main+0xea) [0x7eff7af12f6a]
	/home/owner/GitHub/mono/mono/mini/mono(_start+0x2a) [0x563d5d03fbca]

Debug info from gdb:

[New LWP 23423]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007eff7b4d2687 in waitpid () from /usr/lib/libpthread.so.0
  Id   Target Id         Frame 
* 1    Thread 0x7eff7bfd9780 (LWP 23384) "mono" 0x00007eff7b4d2687 in waitpid () from /usr/lib/libpthread.so.0
  2    Thread 0x7eff7a7ff700 (LWP 23423) "SGen worker" 0x00007eff7b4ce38d in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0

Thread 2 (Thread 0x7eff7a7ff700 (LWP 23423)):
#0  0x00007eff7b4ce38d in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x0000563d5d2d140a in mono_os_cond_wait (mutex=0x563d5d632860 <lock>, cond=0x563d5d632820 <work_cond>) at ../../mono/utils/mono-os-mutex.h:173
#2  get_work (job=<synthetic pointer>, do_idle=<synthetic pointer>, work_context=<synthetic pointer>, worker_index=0) at sgen-thread-pool.c:165
#3  thread_func (data=<optimized out>) at sgen-thread-pool.c:196
#4  0x00007eff7b4c808a in start_thread () from /usr/lib/libpthread.so.0
#5  0x00007eff7afe847f in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7eff7bfd9780 (LWP 23384)):
#0  0x00007eff7b4d2687 in waitpid () from /usr/lib/libpthread.so.0
#1  0x0000563d5d0ccb05 in mono_handle_native_crash (signal=0x563d5d318db6 "SIGABRT", ctx=<optimized out>, info=<optimized out>) at mini-exceptions.c:2813
#2  <signal handler called>
#3  0x00007eff7af268a0 in raise () from /usr/lib/libc.so.6
#4  0x00007eff7af27f09 in abort () from /usr/lib/libc.so.6
#5  0x0000563d5d2db7e0 in mono_log_write_logfile (log_domain=<optimized out>, level=<optimized out>, hdr=<optimized out>, message=0x563d5e587510 "* Assertion: should not be reached at mini-amd64.c:6503\n") at mono-log-common.c:135
#6  0x0000563d5d2f0c5d in monoeg_g_logv (log_domain=log_domain@entry=0x0, log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x563d5d2fa290 "* Assertion: should not be reached at %s:%d\n", args=args@entry=0x7ffd698646e0) at goutput.c:115
#7  0x0000563d5d2f0df3 in monoeg_assertion_message (format=format@entry=0x563d5d2fa290 "* Assertion: should not be reached at %s:%d\n") at goutput.c:135
#8  0x0000563d5d15310f in mono_arch_output_basic_block (cfg=cfg@entry=0x563d5e596f20, bb=bb@entry=0x563d5e597b28) at mini-amd64.c:6503
#9  0x0000563d5d167eb5 in mono_codegen (cfg=cfg@entry=0x563d5e596f20) at mini.c:2250
#10 0x0000563d5d169fb3 in mini_method_compile (method=method@entry=0x563d5e593540, opts=opts@entry=370239999, domain=domain@entry=0x563d5e538820, flags=flags@entry=JIT_FLAG_RUN_CCTORS, parts=parts@entry=0, aot_method_index=aot_method_index@entry=-1) at mini.c:3837
#11 0x0000563d5d16ae54 in mono_jit_compile_method_inner (method=method@entry=0x563d5e593540, target_domain=target_domain@entry=0x563d5e538820, opt=opt@entry=370239999, error=error@entry=0x7ffd69864d50) at mini.c:4181
#12 0x0000563d5d044075 in mono_jit_compile_method_with_opt (method=method@entry=0x563d5e593540, opt=370239999, jit_only=jit_only@entry=0, error=error@entry=0x7ffd69864d50) at mini-runtime.c:2130
#13 0x0000563d5d044e9c in mono_jit_compile_method (method=method@entry=0x563d5e593540, error=error@entry=0x7ffd69864d50) at mini-runtime.c:2176
#14 0x0000563d5d045235 in mono_jit_runtime_invoke (method=0x563d5e593540, obj=<optimized out>, params=0x7ffd69864cf0, exc=0x0, error=0x7ffd69864d50) at mini-runtime.c:2688
#15 0x0000563d5d210e55 in do_runtime_invoke (method=0x563d5e593540, obj=<optimized out>, params=<optimized out>, exc=<optimized out>, error=0x7ffd69864d50) at object.c:2887
#16 0x0000563d5d1b7cb1 in create_exception_two_strings (klass=<optimized out>, a1=a1@entry=0x7eff7a800018, a2=a2@entry=0x0, error=error@entry=0x7ffd69864d50) at exception.c:159
#17 0x0000563d5d1b7fde in mono_exception_from_name_two_strings_checked (image=<optimized out>, name_space=name_space@entry=0x563d5d3241f8 "System", name=name@entry=0x563d5d30a08f "OutOfMemoryException", a1=a1@entry=0x7eff7a800018, a2=a2@entry=0x0, error=error@entry=0x7ffd69864d50) at exception.c:215
#18 0x0000563d5d18aaf0 in create_domain_objects (domain=domain@entry=0x563d5e538820) at appdomain.c:207
#19 0x0000563d5d18cd38 in mono_runtime_init_checked (domain=domain@entry=0x563d5e538820, start_cb=start_cb@entry=0x563d5d040c40 <mono_thread_start_cb>, attach_cb=attach_cb@entry=0x563d5d040bf0 <mono_thread_attach_cb>, error=error@entry=0x7ffd69864f20) at appdomain.c:302
#20 0x0000563d5d0483da in mini_init (filename=<optimized out>, runtime_version=runtime_version@entry=0x0) at mini-runtime.c:4061
#21 0x0000563d5d0996f4 in mono_main (argc=10, argv=<optimized out>) at driver.c:2248
#22 0x0000563d5d03f5f1 in mono_main_with_options (argv=<optimized out>, argc=<optimized out>) at main.c:47
#23 main (argc=<optimized out>, argv=<optimized out>) at main.c:340

=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

make[8]: *** [build/profiles/basic.make:116: build/deps/basic-profile-check.exe] Aborted (core dumped)
*** The contents of your 'monolite-linux/1051100001' directory may be out-of-date
*** You may want to try 'make get-monolite-latest'
make[8]: *** [build/profiles/basic.make:98: do-profile-check-monolite] Error 1
make[7]: *** [build/profiles/basic.make:74: do-profile-check] Error 2
make[6]: *** [build/profiles/basic.make:110: do-profile-check-monolite] Error 2
make[5]: *** [build/profiles/basic.make:74: do-profile-check] Error 2
make[4]: *** [Makefile:54: profile-do--basic--all] Error 2
make[3]: *** [Makefile:50: profiles-do--all] Error 2
make[2]: *** [Makefile:606: all-local] Error 2
make[2]: Leaving directory '/home/owner/GitHub/mono/runtime'
make[1]: *** [Makefile:551: all-recursive] Error 1
make[1]: Leaving directory '/home/owner/GitHub/mono'
make: *** [Makefile:481: all] Error 2
[owner@ST328-OX790-B mono]$ 

moved from mono/mono-addins#90

mono_os_mutex_lock: pthread_mutex_lock failed (failing in mac mono 5.8.0.88, but not in linux mono 5.8.0.22)

Hello,

I'm trying to integrate mono and C, and everything looked good on linux, but when trying the same thing in mac i'm getting the failure:

mono_os_mutex_lock: pthread_mutex_lock failed with "Invalid argument" (22)

On mac, i'm able to compile everything the same way as in linux, using gcc and msbuild, but when executing with mono it fails.

I then found this example https://github.com/xplicit/PInvokePerf and give it a try, again it worked just fine in linux, but failed the same way in mac.

Is this something anyone out there has seen and maybe can help me figure what i'm doing wrong?

This is the mono i'm using on mac:

$ mono --version
Mono JIT compiler version 5.8.0.88 (2017-10/ddeba6e1bab Tue Nov 28 09:38:13 EST 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           normal
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          yes(3.6.0svn-mono-master/8b1520c8aae)
	GC:            sgen (concurrent by default)

On linux i'm using 5.8.0.22

The trace i get when running Sergey Zhukov's example on Mac (i only changed his makefile to use msbuild instead of xbuild) is:

mono_os_mutex_lock: pthread_mutex_lock failed with "Invalid argument" (22)
Stacktrace:

  at  <0xffffffff>
  at (wrapper managed-to-native) PInvokePerf.PerformanceTest.InitInternals () [0x00002] in :0
  at PInvokePerf.MainClass.Main (string[]) [0x00005] in :0
  at (wrapper runtime-invoke) .runtime_invoke_void_object (object,intptr,intptr,intptr) [0x0004e] in :0

Native stacktrace:

	0   mono                                0x000000010736bdc1 mono_handle_native_crash + 257
	1   libsystem_platform.dylib            0x00007fffa692bb3a _sigtramp + 26
	2   ???                                 0x00007fff5894fde0 0x0 + 140734679547360
	3   libsystem_c.dylib                   0x00007fffa67b0420 abort + 129
	4   libmonosgen-2.0.1.dylib             0x000000010a6acb39 monoeg_log_default_handler + 105
	5   libmonosgen-2.0.1.dylib             0x000000010a6acc0e monoeg_g_log + 206
	6   libmonosgen-2.0.1.dylib             0x000000010a572981 mono_add_internal_call + 161
	7   libperf.so                          0x0000000109a9ade7 init + 23
	8   ???                                 0x000000010999f227 0x0 + 4456051239
	9   mono                                0x00000001072c1c57 mono_jit_runtime_invoke + 1383
	10  mono                                0x00000001074821a4 do_runtime_invoke + 84
	11  mono                                0x00000001074857c9 do_exec_main_checked + 137
	12  mono                                0x000000010732ecbf mono_jit_exec + 287
	13  mono                                0x00000001073314b4 mono_main + 9140
	14  mono                                0x00000001072b163d main + 253
	15  mono                                0x00000001072b1534 start + 52
	16  ???                                 0x0000000000000002 0x0 + 2

Debug info from gdb:

(lldb) command source -s 0 '/tmp/mono-gdb-commands.2ZOmzM'
Executing commands in '/tmp/mono-gdb-commands.2ZOmzM'.
(lldb) process attach --pid 50560
warning: (x86_64) /Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/4.5/mscorlib.dll.dylib empty dSYM file detected, dSYM was created with an executable with no debug info.
warning: (x86_64) /Library/Frameworks/Mono.framework/Versions/5.8.0/lib/libglib-2.0.0.dylib empty dSYM file detected, dSYM was created with an executable with no debug info.
Process 50560 stopped
* thread #1, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fffa684b3ee libsystem_kernel.dylib`__wait4 + 10
libsystem_kernel.dylib`__wait4:
->  0x7fffa684b3ee <+10>: jae    0x7fffa684b3f8            ; <+20>
    0x7fffa684b3f0 <+12>: movq   %rax, %rdi
    0x7fffa684b3f3 <+15>: jmp    0x7fffa6843cd4            ; cerror
    0x7fffa684b3f8 <+20>: retq   

Executable module set to "/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono".
Architecture set to: x86_64h-apple-macosx.
(lldb) thread list
Process 50560 stopped
* thread #1: tid = 0x7df80, 0x00007fffa684b3ee libsystem_kernel.dylib`__wait4 + 10, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  thread #2: tid = 0x7df81, 0x00007fffa684abf2 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'SGen worker'
  thread #3: tid = 0x7df82, 0x00007fffa6843386 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Finalizer'
  thread #4: tid = 0x7df83, 0x00007fffa684b44e libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #5: tid = 0x7df85, 0x00007fffa684b44e libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #6: tid = 0x7df88, 0x00007fffa684b44e libsystem_kernel.dylib`__workq_kernreturn + 10
(lldb) thread backtrace all
* thread #1, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fffa684b3ee libsystem_kernel.dylib`__wait4 + 10
    frame #1: 0x000000010736be4e mono`mono_handle_native_crash(signal=, ctx=, info=) at mini-exceptions.c:2726 [opt]
    frame #2: 0x00007fffa692bb3a libsystem_platform.dylib`_sigtramp + 26
    frame #3: 0x00007fffa684ad43 libsystem_kernel.dylib`__pthread_kill + 11
    frame #4: 0x00007fffa6938457 libsystem_pthread.dylib`pthread_kill + 90
    frame #5: 0x00007fffa67b0420 libsystem_c.dylib`abort + 129
    frame #6: 0x000000010a6acb39 libmonosgen-2.0.1.dylib`monoeg_log_default_handler(log_domain=, log_level=, message=, unused_data=) at goutput.c:234 [opt]
    frame #7: 0x000000010a6acc0e libmonosgen-2.0.1.dylib`monoeg_g_log [inlined] monoeg_g_logv at goutput.c:115 [opt]
    frame #8: 0x000000010a6acbc8 libmonosgen-2.0.1.dylib`monoeg_g_log(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format=) at goutput.c:125 [opt]
    frame #9: 0x000000010a572981 libmonosgen-2.0.1.dylib`mono_add_internal_call [inlined] mono_os_mutex_lock(mutex=) at mono-os-mutex.h:101 [opt]
    frame #10: 0x000000010a572954 libmonosgen-2.0.1.dylib`mono_add_internal_call [inlined] mono_icall_lock at icall.c:8147 [opt]
    frame #11: 0x000000010a572954 libmonosgen-2.0.1.dylib`mono_add_internal_call(name=, method=0x0000000109a9ab80) at icall.c:8205 [opt]
    frame #12: 0x0000000109a9ade7 libperf.so`init at libperf.c:152 [opt]
    frame #13: 0x000000010999f227
    frame #14: 0x00000001072c1c57 mono`mono_jit_runtime_invoke(method=, obj=, params=0x00007fff589506d8, exc=0x00007f8011042810, error=) at mini-runtime.c:2800 [opt]
    frame #15: 0x00000001074821a4 mono`do_runtime_invoke(method=0x00007f8010c12218, obj=0x0000000000000000, params=0x00007fff589506d8, exc=0x0000000000000000, error=0x00007fff58950718) at object.c:2849 [opt]
    frame #16: 0x00000001074857c9 mono`do_exec_main_checked [inlined] mono_runtime_invoke_checked(method=, obj=, error=) at object.c:3002 [opt]
    frame #17: 0x0000000107485788 mono`do_exec_main_checked(method=0x00007f8010c12218, args=, error=0x00007fff58950718) at object.c:4726 [opt]
    frame #18: 0x000000010732ecbf mono`mono_jit_exec(domain=, assembly=, argc=1, argv=0x00007fff58950a38) at driver.g.c:1040 [opt]
    frame #19: 0x00000001073314b4 mono`mono_main [inlined] main_thread_handler at driver.g.c:1109 [opt]
    frame #20: 0x0000000107331481 mono`mono_main(argc=2, argv=) at driver.g.c:2222 [opt]
    frame #21: 0x00000001072b163d mono`main [inlined] mono_main_with_options(argc=, argv=) at main.c:46 [opt]
    frame #22: 0x00000001072b1629 mono`main(argc=2, argv=) at main.c:339 [opt]
    frame #23: 0x00000001072b1534 mono`start + 52

...

Can't build mono using Roslyn C# compiler when MONO_DEBUG env var is set

The build of the 5.8.0.88 tarball from https://download.mono-project.com/sources/mono/mono-5.8.0.88.tar.bz2
hangs at CSC [basic] mscorlib.dll.

System:

  • RHEL 6.8
  • gcc 4.4.7
  • python 2.7.9
  • No existing mono installation (i.e. uses monolite)

Steps to build:

wget https://download.mono-project.com/sources/mono/mono-5.8.0.88.tar.bz2
tar -xjf mono-5.8.0.88.tar.bz2
cd mono-5.8.0.88
./configure --disable-rpath --enable-big-arrays --with-large-heap --prefix=/home/${USER}/local/mono/MONO-5.8.0-GCC-4.4.7 --enable-btls=no
## make hangs at 'CSC     [basic] mscorlib.dll'
make

The same build steps for mono-5.4.1.6.tar.bz2 build correctly.

[edit 2018-01-09]:
Relevant Mono environment variables exposing the problem:
MONO_DEBUG=gdb

CreateDelegate does not allow integer argument for enum parameter type

Steps to Reproduce

  1. Compile and run the following test case
using System;

public class Foo
{
    public static int Main(string[] args)
    {
        var action = ((Action<Int32>)Delegate.CreateDelegate(typeof(Action<Int32>), new Foo(), typeof(Foo).GetMethod("Bar")));
        action(2);
        return 0;
    }
    public void Bar(Enum22 e)
    {
        System.Console.WriteLine(e);
    }

    public enum Enum22
    {
        none,
        one,
        two
    }
}

Current Behavior

System.ArgumentException: method arguments are incompatible

Expected Behavior

two

Version Used:

Mono JIT compiler version 5.4.1.4 (2017-06/c6605763a36 Fri Oct 13 15:34:43 EDT 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           normal
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          yes(3.6.0svn-mono-master/8b1520c8aae)
	GC:            sgen (concurrent by default)

Stacktrace

System.ArgumentException: method arguments are incompatible
  at System.Delegate.CreateDelegate (System.Type type, System.Object firstArgument, System.Reflection.MethodInfo method, System.Boolean throwOnBindFailure, System.Boolean allowClosed) [0x00314] in /Users/builder/data/lanes/4992/mono-mac-sdk/external/bockbuild/builds/mono-x64/mcs/class/corlib/System/Delegate.cs:287 
  at System.Delegate.CreateDelegate (System.Type type, System.Object firstArgument, System.Reflection.MethodInfo method) [0x00000] in /Users/builder/data/lanes/4992/mono-mac-sdk/external/bockbuild/builds/mono-x64/mcs/class/corlib/System/Delegate.cs:292 
  at Foo.Main (System.String[] args) [0x00023] in <f2806fa879244491bc711eb9fad8c5f9>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentException: method arguments are incompatible
  at System.Delegate.CreateDelegate (System.Type type, System.Object firstArgument, System.Reflection.MethodInfo method, System.Boolean throwOnBindFailure, System.Boolean allowClosed) [0x00314] in /Users/builder/data/lanes/4992/mono-mac-sdk/external/bockbuild/builds/mono-x64/mcs/class/corlib/System/Delegate.cs:287 
  at System.Delegate.CreateDelegate (System.Type type, System.Object firstArgument, System.Reflection.MethodInfo method) [0x00000] in /Users/builder/data/lanes/4992/mono-mac-sdk/external/bockbuild/builds/mono-x64/mcs/class/corlib/System/Delegate.cs:292 
  at Foo.Main (System.String[] args) [0x00023] in <f2806fa879244491bc711eb9fad8c5f9>:0 

Provide line number information in log profiler backtraces

On the surface, this seems simple enough: We can get this information more or less the same way we do when generating backtraces for exceptions. Where it gets a bit more complicated is when we have to get the information for async backtraces collected during sampling.

Additionally, we would need to come up with a good way to encode this information in the format without it taking up a tremendous amount of space. Writing file name + line number + column number for every frame is obviously not feasible. One possibility is that we only encode an IL offset for each frame and let readers figure things out from there (would require #6180 and #6181).


Originally filed at: https://bugzilla.xamarin.com/show_bug.cgi?id=29904

Expand the log profiler's command server

The Xamarin Profiler team would like to be able to do the same things through the command server which are currently possible through the LogProfiler class in the Mono.Profiler.Log assembly.

Provide field metadata events in the profiler

The profiler should capture and expose field types, names, and offsets. With this information, a complete object retention graph with detailed field information could be constructed from a heapshot.

Additionally, once #6144 is merged, field offsets would make it possible to narrow down exactly which static field a root comes from.

pdb2mdb crashes on .net 4.6 dll

Steps to Reproduce

  1. Create .net 4.6 c# library project in VS
  2. Add a single class with no functionality
  3. Build project
  4. Run pdb2mdb on build dll

Current Behavior

Crash

Expected Behavior

mdb file created

On which platforms did you notice this

  • macOS
  • Linux
  • Windows

Version Used:

pdb2mdb 4.2.3.4 from mono.unofficial.pdb2mdb nuget
VS 2017

Stacktrace

Fatal error:
System.OutOfMemoryException: Array dimensions exceeded supported range.
   at Microsoft.Cci.Pdb.MsfDirectory..ctor(PdbReader reader, PdbFileHeader head, BitAccess bits)
   at Microsoft.Cci.Pdb.PdbFile.LoadFunctions(Stream read, BitAccess bits, Boolean readAllStrings)
   at Pdb2Mdb.Driver.Convert(AssemblyDefinition assembly, Stream pdb, MonoSymbolWriter mdb)

I also tried using the pdb2mdb bundled with Unity at Data\MonoBleedingEdge\lib\mono\4.5\pdb2mdb.exe. That just printed the usage with no error.

Crash in profiler stress test runner when waiting for a process

Steps to Reproduce

  1. Build Mono on Linux armel or OS X i386.
  2. cd acceptance-tests
  3. make check-profiler-stress

Current Behavior

A crash occurs when waiting on a child (test) process to exit.

Expected Behavior

The test runner should run to completion.

Version Used:

2d43cf6

Stacktrace

https://jenkins.mono-project.com/job/test-mono-mainline-linux-profilerstress-arm/label=debian-8-armel-on-arm64/68/consoleFull#-2001780300c04ca618-a109-447b-99e0-481aaedae630

https://jenkins.mono-project.com/job/test-mono-mainline-profilerstress/label=osx-i386/151/consoleFull#-2001780300c04ca618-a109-447b-99e0-481aaedae630

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.