SUMMARY I'm getting an 'Unrecognised instruction' in a system library while running a MacOS GTK3 app. This is running on OSX 10.13.6. STEPS TO REPRODUCE 1. Build v3.15.0 from source and install. I got the tarball from https://sourceware.org/pub/valgrind/valgrind-3.15.0.tar.bz2 2. I got gdb installed from macports, create a code signing cert and signed it. 3. Run valgrind with 'valgrind --vgdb=yes --vgdb-error=0 ./Scribe' 4. Run gdb with 'gdb ./Scribe' 5. Attach to valgrind in gdb 'target remote | /usr/local/lib/valgrind/../../bin/vgdb' 6. Gdb: 'c' OBSERVED RESULT ==875== Memcheck, a memory error detector ==875== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==875== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==875== Command: ./Scribe ==875== ==875== (action at startup) vgdb me ... ==875== ==875== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==875== /path/to/gdb ./Scribe ==875== and then give GDB the following command ==875== target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=875 ==875== --pid is optional if only one valgrind process is running ==875== --875-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --875-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --875-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) --875-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times) ==875== valgrind: Unrecognised instruction at address 0x1044b4b7b. ==875== at 0x1044B4B7B: _dispatch_kq_poll (in /usr/lib/system/libdispatch.dylib) ==875== by 0x1044B4741: _dispatch_kq_drain (in /usr/lib/system/libdispatch.dylib) ==875== by 0x1044B3B0F: _dispatch_kq_unote_update (in /usr/lib/system/libdispatch.dylib) ==875== by 0x1044AEE3E: _dispatch_source_refs_register (in /usr/lib/system/libdispatch.dylib) ==875== by 0x1044AEF68: _dispatch_source_finalize_activation (in /usr/lib/system/libdispatch.dylib) ==875== by 0x1044A7F54: _dispatch_queue_resume_finalize_activation (in /usr/lib/system/libdispatch.dylib) ==875== by 0x1048DF581: _notify_lib_init (in /usr/lib/system/libsystem_notify.dylib) ==875== by 0x1048DFB89: notify_register_dispatch (in /usr/lib/system/libsystem_notify.dylib) ==875== by 0x103554ACF: __CFNotificationCenterGetLocalCenter_block_invoke (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==875== by 0x104496DB7: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib) ==875== by 0x104496D6A: dispatch_once_f (in /usr/lib/system/libdispatch.dylib) ==875== by 0x103554A68: CFNotificationCenterGetLocalCenter (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==875== Your program just tried to execute an instruction that Valgrind ==875== did not recognise. There are two possible reasons for this. ==875== 1. Your program has a bug and erroneously jumped to a non-code ==875== location. If you are running Memcheck and you just saw a ==875== warning about a bad jump, it's probably your program's fault. ==875== 2. The instruction is legitimate but Valgrind doesn't handle it, ==875== i.e. it's Valgrind's fault. If you think this is the case or ==875== you are not sure, please let us know and we'll try to fix it. ==875== Either way, Valgrind will now raise a SIGILL signal which will ==875== probably kill your program. Then in gdb: (gdb) disassemble 0x1044b4b7b,0x1044b4d00 Dump of assembler code from 0x1044b4b7b to 0x1044b4d00: => 0x00000001044b4b7b: ud2 0x00000001044b4b7d: push %rbp 0x00000001044b4b7e: push %r15 0x00000001044b4b80: push %r14 0x00000001044b4b82: push %r13 0x00000001044b4b84: push %r12 0x00000001044b4b86: push %rbx (gdb) x/30xb 0x1044b4b7b 0x1044b4b7b: 0x0f 0x0b 0x55 0x41 0x57 0x41 0x56 0x41 0x1044b4b83: 0x55 0x41 0x54 0x53 0x65 0x4c 0x8b 0x04 0x1044b4b8b: 0x25 0xe8 0x00 0x00 0x00 0x41 0xbb 0x04 0x1044b4b93: 0x00 0x00 0x00 0x40 0xf6 0xc6 EXPECTED RESULT Program runs without illegal instruction. SOFTWARE/OS VERSIONS macOS: 10.13.6 valgrind: 3.15.0 gdb: ADDITIONAL INFORMATION The exact binary I'm trying to valgrind is here: http://memecode.com/inscribe/debug/Scribe.app.zip
*** This bug has been marked as a duplicate of bug 191062 ***
Actually I don't think closing this as dupe is a good idea because I suspect hitting ud2 is just a result of it trying to abort - the real problem here is not understanding how to deal with the mach message.
Hi memecode, Thanks for the macOS bug report. This one is already identified and being tracked at bz#406681. Tom Hughes is right that hitting ud2 is the result of an abort -- but it's unrelated to the unhandled MACH_SEND_TRAILER option. Instead, we are tracking a bug on macOS within _dispatch_kq_poll(). *** This bug has been marked as a duplicate of bug 406681 ***