https://bugs.kde.org/show_bug.cgi?id=383723
Bug ID: 383723
Summary: MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2
opcode
Product: valgrind
Version: 3.14 SVN
Platform: Compiled Sources
OS: OS X
Status: UNCONFIRMED
Severity: crash
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: imol00+...@gmail.com
Target Milestone: ---
I sent this to the mailing list. It was reviewed by John Reiser (thanks John!)
and he asked that I file this report.
Here are the details I supplied:
Running callgrind on my Qt-based app on macOS 10.12.6 crashes.
Running callgrind on "/bin/date" works (which is not surprising as I think
workq_ops is related to threads?)
- 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:
QT += core
QT -= gui
CONFIG += c++11
TARGET = valgrind-test2
CONFIG -= app_bundle
TEMPLATE = app
SOURCES += main.cpp
And main.cpp looks like this:
#include <QCoreApplication>
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
return a.exec();
}
Run valgrind --tool=callgrind <path-to-command-line-executable>
Results:
==35785== Callgrind, a call-graph generating cache profiler
==35785== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
==35785== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright
info
==35785== Command:
/Users/maloney/dev/build-valgrind-test2-Qt_5_x-Profile/valgrind-test2
==35785==
==35785== For interactive control, run 'callgrind_control -h'.
--35785-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--35785-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2
times)
--35785-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4
times)
UNKNOWN workq_ops option 128
==35785== valgrind: Unrecognised instruction at address 0x103b0fb50.
==35785== at 0x103B0FB50: _dispatch_kq_init (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0D8FB: _dispatch_client_callout (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0D8B8: dispatch_once_f (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0FA90: _dispatch_kq_update (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B110CD: _dispatch_kevent_resume (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B1103D: _dispatch_source_kevent_resume (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B10E85: _dispatch_source_kevent_register (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B20651: _dispatch_queue_resume_finalize_activation (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103E603C0: _notify_lib_init (in
/usr/lib/system/libsystem_notify.dylib)
==35785== by 0x103E609AB: notify_register_dispatch (in
/usr/lib/system/libsystem_notify.dylib)
==35785== by 0x1027E8916: CFUniCharMapTo (in
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==35785== by 0x103B0D8FB: _dispatch_client_callout (in
/usr/lib/system/libdispatch.dylib)
==35785== Your program just tried to execute an instruction that Valgrind
==35785== did not recognise. There are two possible reasons for this.
==35785== 1. Your program has a bug and erroneously jumped to a non-code
==35785== location. If you are running Memcheck and you just saw a
==35785== warning about a bad jump, it's probably your program's fault.
==35785== 2. The instruction is legitimate but Valgrind doesn't handle it,
==35785== i.e. it's Valgrind's fault. If you think this is the case or
==35785== you are not sure, please let us know and we'll try to fix it.
==35785== Either way, Valgrind will now raise a SIGILL signal which will
==35785== probably kill your program.
==35785==
==35785== Process terminating with default action of signal 4 (SIGILL)
==35785== Illegal opcode at address 0x103B0FB50
==35785== at 0x103B0FB50: _dispatch_kq_init (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0D8FB: _dispatch_client_callout (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0D8B8: dispatch_once_f (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0FA90: _dispatch_kq_update (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B110CD: _dispatch_kevent_resume (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B1103D: _dispatch_source_kevent_resume (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B10E85: _dispatch_source_kevent_register (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B20651: _dispatch_queue_resume_finalize_activation (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103E603C0: _notify_lib_init (in
/usr/lib/system/libsystem_notify.dylib)
==35785== by 0x103E609AB: notify_register_dispatch (in
/usr/lib/system/libsystem_notify.dylib)
==35785== by 0x1027E8916: CFUniCharMapTo (in
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==35785== by 0x103B0D8FB: _dispatch_client_callout (in
/usr/lib/system/libdispatch.dylib)
==35785==
==35785== Events : Ir
==35785== Collected : 188406082
==35785==
==35785== I refs: 188,406,082
Illegal instruction: 4
John's response and analysis:
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.
--
You are receiving this mail because:
You are watching all bug changes.
