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
The 0x0F 0x0B is ud2 so it has deliberately executed an undefined instruction in order to abort the program
Ignore that comment, that was part of the error handling. The first undefined instruction was roundsd, which is an sse4.1 instruction and therefore probably implemtned in 32 bit mode.
*** Bug 342192 has been marked as a duplicate of this bug. ***
roundsd is an SSE4.1 instruction. SSE4 isn't supported in 32 bit mode, only 64 bit mode. 32 bit mode supports only up to and including SSSE3. http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits There are no current plans to support SSE4 on 32-bit. Please use 64-bit.
*** Bug 350062 has been marked as a duplicate of this bug. ***