- (again this is macOS 10.12.x)
- in Qt Creator, add a new project
- select "Qt Console Application"
- edit its qmake file to remove "CONFIG += console" (this shouldn't be added on
the Mac)
- build "Profile" version
The .pro looks like this:
[[snip]]
Thank you for providing the reproducible test case. It helps *tremendously*!
Action: Please file a bug report (see
http://valgrind.org/support/bug_reports.html).
Use the title "MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode" or
similar.
Include (copy+paste) your test case and the analysis below. A bug report gets
on the authoritative list of things to do; the mailing lists are ephemeral.
I was able to reproduce the problem using --tool=none, so it is not specific
to memcheck, callgrind, etc. I am running MacOS Sierra Version 10.12.6.
The code in system library libdispatch.dylib expects there to be a trap
handler for opcode 'ud2' (0f 0b) [generates SIGILL] which the valgrind
emulator has disabled through some means, perhaps unknowing or inadvertent.
[Or, perhaps some even-more-global protocol (that would have avoided the 'ud2')
has been violated.]
=====
$ valgrind --tool=none
~jreiser/build-valgrind_test2-Desktop_Qt_5_9_1_clang_64bit-Profile/valgrind_test2
==43499== Nulgrind, the minimal Valgrind tool
==43499== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote.
==43499== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==43499== Command:
/Users/jreiser/build-valgrind_test2-Desktop_Qt_5_9_1_clang_64bit-Profile/valgrind_test2
==43499==
--43499-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--43499-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--43499-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
UNKNOWN workq_ops option 128
==43499== valgrind: Unrecognised instruction at address 0x103b1fb50.
==43499== at 0x103B1FB50: _dispatch_kq_init (in
/usr/lib/system/libdispatch.dylib)
==43499== by 0x103B1D8FB: _dispatch_client_callout (in
/usr/lib/system/libdispatch.dylib)
[[snip]]
=====
Running valgrind under lldb, and disassembling after the SIGILL:
=====
(lldb) x/12i 0x103b1fb1f
0x103b1fb1f: e8 2e 48 02 00 callq 0x103b44352
0x103b1fb24: 83 f8 ff cmpl $-0x1, %eax
0x103b1fb27: 0f 85 a1 00 00 00 jne 0x103b1fbce
0x103b1fb2d: e8 e8 46 02 00 callq 0x103b4421a
0x103b1fb32: 48 63 00 movslq (%rax), %rax
0x103b1fb35: 48 83 f8 04 cmpq $0x4, %rax
0x103b1fb39: 74 bf je 0x103b1fafa
0x103b1fb3b: 48 8d 0d dd 71 02 00 leaq 0x271dd(%rip), %rcx
0x103b1fb42: 48 89 0d f7 cc 04 00 movq %rcx, 0x4ccf7(%rip)
0x103b1fb49: 48 89 05 20 cd 04 00 movq %rax, 0x4cd20(%rip)
=> 0x103b1fb50: 0f 0b ud2
0x103b1fb52: f6 03 01 testb $0x1, (%rbx)
=====
Obviously %rax and %rcx (and/or 64-bit memory locations (0x4ccf7+0x103b1fb49)
and (0x4cd20+0x103b1fb50)) contain two parameters to some subroutine
that is invoked by the signal handler for the 'ud2' opcode (which generates
SIGILL or its MacOS equivalent). So perhaps valgrind should restore
the original signal handler for SIGILL during the single instruction 'ud2';
or, libdispatch.dylib may be assuming some other protocol that valgrind
does not know about, etc.
Details:
I had only XCode already installed. It took a couple hours to download
and install the free version of QtCreator (default version 5.9.1),
then install MacPorts and homebrew (following
https://paolozaino.wordpress.com/2015/05/05/how-to-install-and-use-autotools-on-mac-os-x/
which aroused suspicion because the most recent update was a couple years old)
so that I could run autogen.sh to build valgrind from current git source.
But I did manage to reproduce the problem, so enough of everything probably
worked.
--
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
