[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723
--- Comment #11 from Andy ---
Created attachment 107858
--> https://bugs.kde.org/attachment.cgi?id=107858&action=edit
{darwin} Accepts and ignores WQOPS_SET_EVENT_MANAGER_PRIORITY
This patch fixes the original issue in this bug report.
It recognizes the WQOPS_SET_EVENT_MANAGER_PRIORITY case and ignores it.
This does not address the second issue in this report (the kevent_qos issue).
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723 Rhys Kidd changed: What|Removed |Added Blocks||365327 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=365327 [Bug 365327] Support macOS Sierra (10.12) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723 Rhys Kidd changed: What|Removed |Added CC||rhysk...@gmail.com Assignee|jsew...@acm.org |rhysk...@gmail.com Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723 --- Comment #10 from Andy --- *bows to Sensei* My guess would be that given that kevent_qos is related to QOS/priorities it probably doesn't carry any interesting info for valgrind and should just be ignored? I will wait for someone else to weigh in. I'd be happy to continue to learn about this with some guidance and see it through to a patch! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723 --- Comment #9 from John Reiser --- > #if DARWIN_VERS >= DARWIN_10_11 > // NYI kevent_qos // 374 > #endif /* DARWIN_VERS >= DARWIN_10_11 */ Yes, that looks like a promising clue. You have now reached the point of knowing as much as I do about what is going on here. I may not be able to lead anymore. I hope your work provides motivation and a head start for someone who knows more about MacOS. Thank you for being a good student, Andy. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723
--- Comment #8 from Andy ---
Ok I did that but it's still giving me roughly the same thing:
ELAPSD SYSCALL(args)= return
35 open("/dev/dtracehelper\0", 0x2, 0x7FFF5834D930) = 3 0
320 ioctl(0x3, 0x80086804, 0x7FFF5834D8B8) = 0 0
6 close(0x3) = 0 0
2 thread_selfid(0x3, 0x80086804, 0x7FFF5834D8B8) = 4487 0
4 bsdthread_register(0x7FFF9894B080, 0x7FFF9894B070, 0x2000)
= 1073741919 0
2 ulock_wake(0x1, 0x7FFF5834D0EC, 0x0) = -1 Err#2
1 issetugid(0x1, 0x7FFF5834D0EC, 0x0) = 0 0
4 mprotect(0x1078B9000, 0x88, 0x1) = 0 0
2 mprotect(0x1078BB000, 0x1000, 0x0) = 0 0
1 mprotect(0x1078D1000, 0x1000, 0x0) = 0 0
1 mprotect(0x1078D2000, 0x1000, 0x0) = 0 0
1 mprotect(0x1078E8000, 0x1000, 0x0) = 0 0
2 mprotect(0x1078E9000, 0x1000, 0x1) = 0 0
3 mprotect(0x1078B9000, 0x88, 0x3) = 0 0
2 mprotect(0x1078B9000, 0x88, 0x1) = 0 0
1 getpid(0x1078B9000, 0x88, 0x1) = 440 0
4 stat64("/AppleInternal/XBS/.isChrooted\0", 0x7FFF5834CFA8, 0x1)
= -1 Err#2
1 stat64("/AppleInternal\0", 0x7FFF5834D040, 0x1) = -1 Err#2
3 csops(0x1B8, 0x7, 0x7FFF5834CAD0)= -1 Err#22
33 sysctl([CTL_KERN, 14, 1, 440, 0, 0] (4), 0x7FFF5834CC28,
0x7FFF5834CC20, 0x0, 0x0) = 0 0
1 ulock_wake(0x1, 0x7FFF5834D050, 0x0) = -1 Err#2
2 csops(0x1B8, 0x7, 0x7FFF5834C3B0)= -1 Err#22
33 stat64("./valgrind-test\0", 0x7FFF5834DB40, 0x7FFF5834C3B0)
= 0 0
35
access("/Users/maloney/dev/lib/valgrind/vgpreload_core-x86-darwin.so\0", 0x5,
0x7FFF5834C3B0)= 0 0
==440== Nulgrind, the minimal Valgrind tool
25
access("/Users/maloney/dev/lib/valgrind/vgpreload_core-amd64-darwin.so\0", 0x5,
0x7FFF5834C3B0) = 0 0
==440== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote.
9
access("/Users/maloney/dev/lib/valgrind/vgpreload_core-arm-darwin.so\0", 0x5,
0x7FFF5834C3B0)= -1 Err#2
==440== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
5
access("/Users/maloney/dev/lib/valgrind/vgpreload_core-ppc32-darwin.so\0", 0x5,
0x7FFF5834C3B0) = -1 Err#2
==440== Command: ./valgrind-test
==440==
5
access("/Users/maloney/dev/lib/valgrind/vgpreload_core-ppc64be-darwin.so\0",
0x5, 0x7FFF5834C3B0)= -1 Err#2
8 access("/Users/maloney/brew/bin/./valgrind-test\0", 0x5,
0x7FFF5834C3B0) = -1 Err#2
2 access("/Users/maloney/research/bin/./valgrind-test\0", 0x5,
0x7FFF5834C3B0) = -1 Err#2
5 access("/Users/maloney/dev/bin/./valgrind-test\0", 0x5, 0x7FFF5834C3B0)
= -1 Err#2
6 access("/usr/local/bin/./valgrind-test\0", 0x5, 0x7FFF5834C3B0)
= -1 Err#2
7 access("/usr/bin/./valgrind-test\0", 0x5, 0x7FFF5834C3B0)
= -1 Err#2
6 access("/bin/./valgrind-test\0", 0x5, 0x7FFF5834C3B0)= -1
Err#2
6 access("/usr/sbin/./valgrind-test\0", 0x5, 0x7FFF5834C3B0)
= -1 Err#2
5 access("/sbin/./valgrind-test\0", 0x5, 0x7FFF5834C3B0) = -1
Err#2
6 open("./valgrind-test\0", 0x0, 0x) = 3 0
233 read(0x3, "\317\372\355\376\a\0", 0x1000)= 4096 0
7 close(0x3) = 0 0
7 open_nocancel(".\0", 0x0, 0x7F87E680)= 3 0
3 fstat64(0x3, 0x7FFF5834D940, 0x7F87E680) = 0 0
7 fcntl_nocancel(0x3, 0x32, 0x7F87E6801000)= 0 0
3 close_nocancel(0x3) = 0 0
4 stat64("/Users/maloney/dev/build-valgrind-test-Qt_5_x-Profile\0",
0x7FFF5834D8B0, 0x7F87E6801000)= 0 0
1 getppid(0x7F87E6801000, 0x7FFF5834D8B0, 0x7F87E6801000) = 437
0
279 access("/Users/maloney/dev/lib/valgrind/none-amd64-darwin\0", 0x5,
0x7F87E6801000) = 0 0
I see that it opened and read from the target executable successfully. It's not
reporting any errors, just terminating. Nothing else here looks problematic to
me - am I missing something?
I'd like to understand why that isn't working, but looking through the
non-valgrind trace, I see something related to QOS which sounds like our
culprit - kevent_qos(). Looking at the valgrind source (priv_syswrap-darwin.h):
#if DARWIN_VERS >= DARWIN_10_11
// NYI kevent_qos // 374
#endif /* DARWIN_VERS >= DARWIN_10_11 */
(Thank you for stepping me through this and for your patience...)
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723 --- Comment #7 from John Reiser --- > dtrace: system integrity protection is on, some features will not be > available You must disable that system integrity protection (that's why the spawn/"execve"/whatever failed.) It's a minor hassle. Search the net, I don't remember the recipe. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723
--- Comment #6 from Andy ---
Thanks John.
I must be doing something wrong.
I can run dtruss on my example ok ("sudo dtruss -e ./valgrind-test").
I can run valgrind on the example ("valgrind --tool=none ./valgrind-test") and
it crashes (as expected).
But when I run dtruss on valgrind on the example ("sudo dtruss -e valgrind
--tool=none ./valgrind-test") it doesn't run the test executable. Here's the
output:
dtrace: system integrity protection is on, some features will not be available
ELAPSD SYSCALL(args)= return
35 open("/dev/dtracehelper\0", 0x2, 0x7FFF58BBD930) = 3 0
346 ioctl(0x3, 0x80086804, 0x7FFF58BBD8B8) = 0 0
6 close(0x3) = 0 0
2 thread_selfid(0x3, 0x80086804, 0x7FFF58BBD8B8) = 2058768 0
4 bsdthread_register(0x7FFFE336D080, 0x7FFFE336D070, 0x2000)
= 1073741919 0
2 ulock_wake(0x1, 0x7FFF58BBD0EC, 0x0) = -1 Err#2
1 issetugid(0x1, 0x7FFF58BBD0EC, 0x0) = 0 0
5 mprotect(0x107049000, 0x88, 0x1) = 0 0
2 mprotect(0x10704B000, 0x1000, 0x0) = 0 0
1 mprotect(0x107061000, 0x1000, 0x0) = 0 0
1 mprotect(0x107062000, 0x1000, 0x0) = 0 0
2 mprotect(0x107078000, 0x1000, 0x0) = 0 0
2 mprotect(0x107079000, 0x1000, 0x1) = 0 0
3 mprotect(0x107049000, 0x88, 0x3) = 0 0
2 mprotect(0x107049000, 0x88, 0x1) = 0 0
1 getpid(0x107049000, 0x88, 0x1) = 58961 0
4 stat64("/AppleInternal/XBS/.isChrooted\0", 0x7FFF58BBCFA8, 0x1)
= -1 Err#2
1 stat64("/AppleInternal\0", 0x7FFF58BBD040, 0x1) = -1 Err#2
3 csops(0xE651, 0x7, 0x7FFF58BBCAD0) = -1 Err#22
dtrace: error on enabled probe ID 2158 (ID 552: syscall::sysctl:return):
invalid kernel access in action #10 at DIF offset 40
1 ulock_wake(0x1, 0x7FFF58BBD050, 0x0) = -1 Err#2
2 csops(0xE651, 0x7, 0x7FFF58BBC3B0) = -1 Err#22
6 stat64("./valgrind-test\0", 0x7FFF58BBDB40, 0x7FFF58BBC3B0)
= 0 0
24
access("/Users/maloney/dev/lib/valgrind/vgpreload_core-x86-darwin.so\0", 0x5,
0x7FFF58BBC3B0)= 0 0
15
access("/Users/maloney/dev/lib/valgrind/vgpreload_core-amd64-darwin.so\0", 0x5,
0x7FFF58BBC3B0) = 0 0
3
access("/Users/maloney/dev/lib/valgrind/vgpreload_core-arm-darwin.so\0", 0x5,
0x7FFF58BBC3B0)= -1 Err#2
2
access("/Users/maloney/dev/lib/valgrind/vgpreload_core-ppc32-darwin.so\0", 0x5,
0x7FFF58BBC3B0) = -1 Err#2
2
access("/Users/maloney/dev/lib/valgrind/vgpreload_core-ppc64be-darwin.so\0",
0x5, 0x7FFF58BBC3B0)= -1 Err#2
==58961== Nulgrind, the minimal Valgrind tool
==58961== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote.
3 access("/Users/maloney/brew/bin/./valgrind-test\0", 0x5,
0x7FFF58BBC3B0) = -1 Err#2
==58961== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright
info
2 access("/Users/maloney/research/bin/./valgrind-test\0", 0x5,
0x7FFF58BBC3B0) = -1 Err#2
==58961== Command: ./valgrind-test
==58961==
2 access("/Users/maloney/dev/bin/./valgrind-test\0", 0x5, 0x7FFF58BBC3B0)
= -1 Err#2
3 access("/usr/local/bin/./valgrind-test\0", 0x5, 0x7FFF58BBC3B0)
= -1 Err#2
2 access("/usr/bin/./valgrind-test\0", 0x5, 0x7FFF58BBC3B0)
= -1 Err#2
2 access("/bin/./valgrind-test\0", 0x5, 0x7FFF58BBC3B0)= -1
Err#2
2 access("/usr/sbin/./valgrind-test\0", 0x5, 0x7FFF58BBC3B0)
= -1 Err#2
2 access("/sbin/./valgrind-test\0", 0x5, 0x7FFF58BBC3B0) = -1
Err#2
7 open("./valgrind-test\0", 0x0, 0x) = 3 0
dtrace: error on enabled probe ID 2134 (ID 154: syscall::read:return): invalid
kernel access in action #12 at DIF offset 92
5 close(0x3) = 0 0
4 open_nocancel(".\0", 0x0, 0x7FB9AB80)= 3 0
2 fstat64(0x3, 0x7FFF58BBD940, 0x7FB9AB80) = 0 0
6 fcntl_nocancel(0x3, 0x32, 0x7FB9AB801000)= 0 0
2 close_nocancel(0x3) = 0 0
3 stat64("/Users/maloney/dev/build-valgrind-test-Qt_5_x-Profile\0",
0x7FFF58BBD8B0, 0x7FB9AB801000)= 0 0
1 getppid(0x7FB9AB801000, 0x7FFF58BBD8B0, 0x7FB9AB801000) =
58958 0
14 access("/Users/maloney/dev/lib/valgrind/none-amd64-darwin\0", 0x5,
0x7FB9AB801000) = 0 0
It looks like it's checking each path for the executable ("access"), then tries
to open the executable and ... fails? I tried it with a full path and get the
same result.
Am I doing that correctly? (Apologies - never used dtruss before, so I'm
relying on online info and experimentation.)
--
You are receiving this mail because:
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723 --- Comment #5 from John Reiser --- The crash looks very similar to the 'ud2' diagnosed in the original Description. In particular, the offset 0xb50 is the same. This probably indicates that valgrind has more-or-less completely missed some aspect of what MacOS is doing. We need advice from an expert. So, spend two weeks at the bar/pub/tavern/restaurants in Cupertino and Sunnyvale. Buy a beer for the next 10 people who enter. Chat them up. Apply dtruss and/or dtrace to the original program without valgrind, and to valgrind when running the program. Correlate the system calls between the two runs; try to understand the difference. [Also investigate "valgrind --trace-syscalls=yes ..." as an additional or alternate source of information.] That's quite tedious, but logically should work. Also, contrast with running on Linux (which uses 'strace'). The Qt implementation might be similar enough to provide a clue. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723 --- Comment #4 from Andy --- Great - thanks John! Those MACH_SEND_TRAILER warnings you mentioned earlier were reported a couple of years ago: https://bugs.kde.org/show_bug.cgi?id=343306 Like you I cannot find any documentation on Darwin's workq except some source code. I found the most recent (released) version of workqueue_internal.h - for macOS 10.12.4: https://opensource.apple.com/source/libpthread/libpthread-218.1.3/kern/workqueue_internal.h.auto.html and where the WQOPS_SET_EVENT_MANAGER_PRIORITY case is processed (see _workq_kernreturn): https://opensource.apple.com/source/libpthread/libpthread-218.1.3/kern/kern_support.c.auto.html and where it is called with this value (see _pthread_workqueue_set_event_manager_priority): https://opensource.apple.com/source/libpthread/libpthread-218.1.3/src/pthread.c.auto.html Based on my reading I think you are correct and it can be ignored for valgrind's purposes because it's for scheduling priorities. Assuming I did things correctly to test this (simply adding "case 128: break;" to PRE(workq_ops)), it now crashes with an "Unrecognised instruction" instead: ==57909== Callgrind, a call-graph generating cache profiler ==57909== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al. ==57909== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==57909== Command: /Users/maloney/dev/build-test-valgrind/test-valgrind.app/Contents/MacOS/test-valgrind ==57909== ==57909== For interactive control, run 'callgrind_control -h'. --57909-- run: /usr/bin/dsymutil "/Users/maloney/dev/build-test-valgrind/test-valgrind.app/Contents/MacOS/test-valgrind" --57909-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --57909-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --57909-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) ==57909== valgrind: Unrecognised instruction at address 0x104018b50. ==57909==at 0x104018B50: _dispatch_kq_init (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x1040168FB: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x1040168B8: dispatch_once_f (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x104018A90: _dispatch_kq_update (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x10401A0CD: _dispatch_kevent_resume (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x10401A03D: _dispatch_source_kevent_resume (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x104019E85: _dispatch_source_kevent_register (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x104029651: _dispatch_queue_resume_finalize_activation (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x105AE43C0: _notify_lib_init (in /usr/lib/system/libsystem_notify.dylib) ==57909==by 0x105AE49AB: notify_register_dispatch (in /usr/lib/system/libsystem_notify.dylib) ==57909==by 0x1049FE916: CFUniCharMapTo (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==57909==by 0x1040168FB: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib) ==57909== Your program just tried to execute an instruction that Valgrind ==57909== did not recognise. There are two possible reasons for this. ==57909== 1. Your program has a bug and erroneously jumped to a non-code ==57909==location. If you are running Memcheck and you just saw a ==57909==warning about a bad jump, it's probably your program's fault. ==57909== 2. The instruction is legitimate but Valgrind doesn't handle it, ==57909==i.e. it's Valgrind's fault. If you think this is the case or ==57909==you are not sure, please let us know and we'll try to fix it. ==57909== Either way, Valgrind will now raise a SIGILL signal which will ==57909== probably kill your program. ==57909== ==57909== Process terminating with default action of signal 4 (SIGILL) ==57909== Illegal opcode at address 0x104018B50 ==57909==at 0x104018B50: _dispatch_kq_init (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x1040168FB: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x1040168B8: dispatch_once_f (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x104018A90: _dispatch_kq_update (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x10401A0CD: _dispatch_kevent_resume (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x10401A03D: _dispatch_source_kevent_resume (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x104019E85: _dispatch_source_kevent_register (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x104029651: _dispatch_queue_resume_finalize_activation (in /usr/lib/system/libdispatch.dylib) ==57909==by 0x105AE43C0: _notify_lib_init (in /usr/lib/system/libsystem_notify.dylib) ==57909==by 0x105AE49AB: notify_register_dispatch (in /usr/lib/system/libsystem_notify.dylib) ==57909==by 0x1049FE916: CFUniCharMapTo (in /System/Library/Fram
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723 --- Comment #3 from John Reiser --- On 09/01/2017 09:18 AM, Andy wrote: > https://bugs.kde.org/show_bug.cgi?id=383723 > > --- Comment #2 from Andy --- > Is there anything else I can provide to help with this? I'm afraid actually > fixing it is beyond my capabilities. > > (It's a blocker for me - and anyone else trying to use valgrind for Qt-based > apps on macOS it seems.) > > Thanks! > Locate some good documentation on MacOS workq. Specifically, find the MacOS source code which handles all workq options, including those that correspond to the cases in PRE(workq_ops) in coregrind/m_syswrap/syswrap-darwin.c . The closest I could find after modest searching is https://opensource.apple.com/source/xnu/xnu-3789.51.2/bsd/kern/pthread_shims.c.auto.html Apparently there used to be a file pthread_synch.c but I cannot find it. I did find https://opensource.apple.com/source/libpthread/libpthread-137.1.1/kern/workqueue_internal.h which does have #define WQOPS_SET_EVENT_MANAGER_PRIORITY 0x80 /* max() in the provided priority in the the priority of the event manager */ and looks like a clue. If so, then option 128 could be a no-op for valgrind. Try that? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723 --- Comment #2 from Andy --- Is there anything else I can provide to help with this? I'm afraid actually fixing it is beyond my capabilities. (It's a blocker for me - and anyone else trying to use valgrind for Qt-based apps on macOS it seems.) Thanks! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383723] MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode
https://bugs.kde.org/show_bug.cgi?id=383723 John Reiser changed: What|Removed |Added CC||jrei...@bitwagon.com --- Comment #1 from John Reiser --- /bin/date gets some of the "prelude" notices under --tool=none, so investigating that could be a warm-up for working on the "UNKNOWN workq_ops option 128". $ valgrind --tool=none /bin/date ==44124== Nulgrind, the minimal Valgrind tool ==44124== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. ==44124== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==44124== Command: /bin/date ==44124== --44124-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --44124-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --44124-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) Mon Aug 21 09:59:20 PDT 2017 ==44124== -- You are receiving this mail because: You are watching all bug changes.
