Re: [Valgrind-users] Crash running callgrind

[John R. <jr...@bi...>]

> - (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.

--