Bug 410562 - Unrecognised instruction 'UD2'
Summary: Unrecognised instruction 'UD2'
Status: RESOLVED DUPLICATE of bug 406681
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.15 SVN
Platform: Compiled Sources macOS
: NOR normal
Target Milestone: ---
Assignee: Rhys Kidd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-04 08:45 UTC by memecode
Modified: 2019-10-03 06:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description memecode 2019-08-04 08:45:55 UTC
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
Comment 1 Tom Hughes 2019-08-04 09:03:03 UTC

*** This bug has been marked as a duplicate of bug 191062 ***
Comment 2 Tom Hughes 2019-08-04 09:05:51 UTC
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.
Comment 3 Rhys Kidd 2019-10-03 06:12:39 UTC
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 ***