Bug 346023

I want to run memecheck on my mono program, but valgrind crashes.
I simplified the test to running nullgrind on helloWorld over mono, but still getting a crash.



Reproducible: Always

Steps to Reproduce:
The program I run is the basic console helloworld over mono, explained in http://www.mono-project.com/docs/getting-started/mono-basics/
I compile hello.cs, and run it without any problem with:
$ mono hello.exe
Then I run
$ valgrind --tool=none   mono hello.exe


Actual Results:  
Complete output follows:

$ valgrind --tool=none   mono hello.exe
==55778== Nulgrind, the minimal Valgrind tool
==55778== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote.
==55778== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==55778== Command: mono hello.exe
==55778== 
--55778-- UNKNOWN host message [id 412, to mach_host_self(), reply 0x40f]
--55778-- UNKNOWN host message [id 222, to mach_host_self(), reply 0x40f]
--55778-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--55778-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--55778-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--55778-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xB
==55778== valgrind: Unrecognised instruction at address 0x182dfd6.
==55778==    at 0x182DFD6: __tanpi (in /usr/lib/system/libsystem_m.dylib)
==55778==    by 0x2068EF: sgen_marksweep_init (in /usr/bin/mono)
==55778==    by 0x1FF327: mono_gc_base_init (in /usr/bin/mono)
==55778==    by 0x1C7097: mono_init_internal (in /usr/bin/mono)
==55778==    by 0x1C8567: mono_init_from_assembly (in /usr/bin/mono)
==55778==    by 0xD854: mini_init (in /usr/bin/mono)
==55778==    by 0x8643A: mono_main (in /usr/bin/mono)
==55778==    by 0x1EEF: main (in /usr/bin/mono)
==55778== Your program just tried to execute an instruction that Valgrind
==55778== did not recognise.  There are two possible reasons for this.
==55778== 1. Your program has a bug and erroneously jumped to a non-code
==55778==    location.  If you are running Memcheck and you just saw a
==55778==    warning about a bad jump, it's probably your program's fault.
==55778== 2. The instruction is legitimate but Valgrind doesn't handle it,
==55778==    i.e. it's Valgrind's fault.  If you think this is the case or
==55778==    you are not sure, please let us know and we'll try to fix it.
==55778== Either way, Valgrind will now raise a SIGILL signal which will
==55778== probably kill your program.

Native stacktrace:

	0   mono                                0x000b9e06 mono_handle_native_sigsegv + 342
	1   mono                                0x0000ccc4 mono_sigsegv_signal_handler + 212
	2   ???                                 0x3802efbd 0x0 + 939716541
	3   mono                                0x00115b39 mono_class_from_name + 441
	4   mono                                0x00137bf5 mono_exception_from_name_domain + 53
	5   mono                                0x0013826e mono_get_exception_execution_engine + 62
	6   mono                                0x0000cbde mono_sigill_signal_handler + 30
	7   ???                                 0x3802efbd 0x0 + 939716541
	8   mono                                0x002068f0 sgen_marksweep_init + 16
	9   mono                                0x001ff328 mono_gc_base_init + 968
	10  mono                                0x001c7098 mono_init_internal + 168
	11  mono                                0x001c8568 mono_init_from_assembly + 24
	12  mono                                0x0000d855 mini_init + 1733
	13  mono                                0x0008643b mono_main + 4891
	14  mono                                0x00001ef0 main + 768
	15  mono                                0x00001be5 start + 53

Debug info from gdb:

==55779== 

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

--55778-- UNKNOWN __pthread_sigmask is unsupported.
--55778-- UNKNOWN __pthread_sigmask is unsupported. (repeated 2 times)
vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x55 0x89
==55778== valgrind: Unrecognised instruction at address 0x1713fe5.
==55778==    at 0x1713FE5: __abort (in /usr/lib/system/libsystem_c.dylib)
==55778==    by 0x1713EFE: abort (in /usr/lib/system/libsystem_c.dylib)
==55778==    by 0xB9FA4: mono_handle_native_sigsegv (in /usr/bin/mono)
==55778==    by 0xCCC3: mono_sigsegv_signal_handler (in /usr/bin/mono)
==55778==    by 0x3802EFBC: ???
==55778==    by 0x115B38: mono_class_from_name (in /usr/bin/mono)
==55778==    by 0x137BF4: mono_exception_from_name_domain (in /usr/bin/mono)
==55778==    by 0x13826D: mono_get_exception_execution_engine (in /usr/bin/mono)
==55778==    by 0xCBDD: mono_sigill_signal_handler (in /usr/bin/mono)
==55778==    by 0x3802EFBC: ???
==55778==    by 0x2068EF: sgen_marksweep_init (in /usr/bin/mono)
==55778==    by 0x1FF327: mono_gc_base_init (in /usr/bin/mono)
==55778== Your program just tried to execute an instruction that Valgrind
==55778== did not recognise.  There are two possible reasons for this.
==55778== 1. Your program has a bug and erroneously jumped to a non-code
==55778==    location.  If you are running Memcheck and you just saw a
==55778==    warning about a bad jump, it's probably your program's fault.
==55778== 2. The instruction is legitimate but Valgrind doesn't handle it,
==55778==    i.e. it's Valgrind's fault.  If you think this is the case or
==55778==    you are not sure, please let us know and we'll try to fix it.
==55778== Either way, Valgrind will now raise a SIGILL signal which will
==55778== probably kill your program.
==55778== 
==55778== Process terminating with default action of signal 10 (SIGBUS)
==55778==  Non-existent physical address at address 0x2D8
==55778==    at 0x124D99: mono_image_init_name_cache (in /usr/bin/mono)
==55778==    by 0x115B38: mono_class_from_name (in /usr/bin/mono)
==55778==    by 0x137BF4: mono_exception_from_name_domain (in /usr/bin/mono)
==55778==    by 0x13826D: mono_get_exception_execution_engine (in /usr/bin/mono)
==55778==    by 0xCBDD: mono_sigill_signal_handler (in /usr/bin/mono)
==55778==    by 0x3802EFBC: ???
==55778==    by 0x1713EFE: abort (in /usr/lib/system/libsystem_c.dylib)
==55778==    by 0xB9FA4: mono_handle_native_sigsegv (in /usr/bin/mono)
==55778==    by 0xCCC3: mono_sigsegv_signal_handler (in /usr/bin/mono)
==55778==    by 0x3802EFBC: ???
==55778==    by 0x115B38: mono_class_from_name (in /usr/bin/mono)
==55778==    by 0x137BF4: mono_exception_from_name_domain (in /usr/bin/mono)
==55778== 
Bus error: 10

Expected Results:  
I expected the usual valgrind output.

Compiled valgrind on OS X from SVN trunk checked out yesterday 2015-04-8.

$ uname -msr
Darwin 14.1.0 x86_64
$ valgrind --version
valgrind-3.11.0.SVN

Seems similar to  "Bug 197266 - valgrind appears to choke on the xmms instruction "roundsd" on x86_64", but it was closed long ago. Also its duplicate Bug 283743


"Bug 344337 - OS X 10.10 unhandled syscall" shows a log that starts with the same text:
UNKNOWN host message [id 412, to mach_host_self(), reply 0x40f]

but then it goes unhandled syscall, instead  of: 
 unhandled instruction bytes: 0x66 0xF 0x3A 0xB