|
From: IMoL <im...@gm...> - 2017-08-17 22:16:10
|
1. macOS 10.12.6 2. built using git: commit ba17add79a563bd1395dc05fa7309baffbcaa3ce (HEAD -> master, origin/master, origin/HEAD) All I did was clone it, run autogen, run configure with a prefix and make install 3. This is a Qt-based application 4. When I run callgrind through Qt Creator on my app it crashes with: ==71159== Callgrind, a call-graph generating cache profiler ==71159== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al. ==71159== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==71159== Command: /Users/maloney/dev/foo/Mac/release/foo.app/Contents/MacOS/foo ==71159== ==71159== For interactive control, run 'callgrind_control -h'. --71159-- run: /usr/bin/dsymutil "/Users/maloney/dev/foo/Mac/release/foo.app/Contents/MacOS/foo" --71159-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --71159-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --71159-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) UNKNOWN workq_ops option 128 ==71159== valgrind: Unrecognised instruction at address 0x10438ab50. ==71159== at 0x10438AB50: _dispatch_kq_init (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x1043888FB: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x1043888B8: dispatch_once_f (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x10438AA90: _dispatch_kq_update (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x10438C0CD: _dispatch_kevent_resume (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x10438C03D: _dispatch_source_kevent_resume (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x10438BE85: _dispatch_source_kevent_register (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x10439B651: _dispatch_queue_resume_finalize_activation (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x1046DB3C0: _notify_lib_init (in /usr/lib/system/libsystem_notify.dylib) ==71159== by 0x1046DB9AB: notify_register_dispatch (in /usr/lib/system/libsystem_notify.dylib) ==71159== by 0x106E59916: CFUniCharMapTo (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==71159== by 0x1043888FB: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib) ==71159== Your program just tried to execute an instruction that Valgrind ==71159== did not recognise. There are two possible reasons for this. ==71159== 1. Your program has a bug and erroneously jumped to a non-code ==71159== location. If you are running Memcheck and you just saw a ==71159== warning about a bad jump, it's probably your program's fault. ==71159== 2. The instruction is legitimate but Valgrind doesn't handle it, ==71159== i.e. it's Valgrind's fault. If you think this is the case or ==71159== you are not sure, please let us know and we'll try to fix it. ==71159== Either way, Valgrind will now raise a SIGILL signal which will ==71159== probably kill your program. ==71159== ==71159== Process terminating with default action of signal 4 (SIGILL) ==71159== Illegal opcode at address 0x10438AB50 ==71159== at 0x10438AB50: _dispatch_kq_init (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x1043888FB: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x1043888B8: dispatch_once_f (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x10438AA90: _dispatch_kq_update (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x10438C0CD: _dispatch_kevent_resume (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x10438C03D: _dispatch_source_kevent_resume (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x10438BE85: _dispatch_source_kevent_register (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x10439B651: _dispatch_queue_resume_finalize_activation (in /usr/lib/system/libdispatch.dylib) ==71159== by 0x1046DB3C0: _notify_lib_init (in /usr/lib/system/libsystem_notify.dylib) ==71159== by 0x1046DB9AB: notify_register_dispatch (in /usr/lib/system/libsystem_notify.dylib) ==71159== by 0x106E59916: CFUniCharMapTo (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==71159== by 0x1043888FB: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib) ==71159== ==71159== Events : Ir ==71159== Collected : 260775396 ==71159== ==71159== I refs: 260,775,396 The program has unexpectedly finished. ** Process crashed ** 5. Looks like "UNKNOWN workq_ops option 128" is the problem, but there isn't a VKI_WQOPS_* define for 128... |
|
From: IMoL <im...@gm...> - 2017-08-19 12:45:37
|
Does anyone have any ideas? Am I doing something incorrectly or missing something? Thanks. - Andy On Thu, Aug 17, 2017 at 6:15 PM, IMoL <im...@gm...> wrote: > 1. macOS 10.12.6 > > 2. built using git: commit ba17add79a563bd1395dc05fa7309baffbcaa3ce (HEAD > -> master, origin/master, origin/HEAD) > > All I did was clone it, run autogen, run configure with a prefix and make > install > > 3. This is a Qt-based application > > 4. When I run callgrind through Qt Creator on my app it crashes with: > > ==71159== Callgrind, a call-graph generating cache profiler > ==71159== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et > al. > ==71159== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for > copyright info > ==71159== Command: /Users/maloney/dev/foo/Mac/release/foo.app/Contents/ > MacOS/foo > ==71159== > ==71159== For interactive control, run 'callgrind_control -h'. > --71159-- run: /usr/bin/dsymutil "/Users/maloney/dev/foo/Mac/ > release/foo.app/Contents/MacOS/foo" > --71159-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option > --71159-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 > times) > --71159-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 > times) > UNKNOWN workq_ops option 128 > ==71159== valgrind: Unrecognised instruction at address 0x10438ab50. > ==71159== at 0x10438AB50: _dispatch_kq_init (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x1043888FB: _dispatch_client_callout (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x1043888B8: dispatch_once_f (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x10438AA90: _dispatch_kq_update (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x10438C0CD: _dispatch_kevent_resume (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x10438C03D: _dispatch_source_kevent_resume (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x10438BE85: _dispatch_source_kevent_register (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x10439B651: _dispatch_queue_resume_finalize_activation > (in /usr/lib/system/libdispatch.dylib) > ==71159== by 0x1046DB3C0: _notify_lib_init (in > /usr/lib/system/libsystem_notify.dylib) > ==71159== by 0x1046DB9AB: notify_register_dispatch (in > /usr/lib/system/libsystem_notify.dylib) > ==71159== by 0x106E59916: CFUniCharMapTo (in /System/Library/Frameworks/ > CoreFoundation.framework/Versions/A/CoreFoundation) > ==71159== by 0x1043888FB: _dispatch_client_callout (in > /usr/lib/system/libdispatch.dylib) > ==71159== Your program just tried to execute an instruction that Valgrind > ==71159== did not recognise. There are two possible reasons for this. > ==71159== 1. Your program has a bug and erroneously jumped to a non-code > ==71159== location. If you are running Memcheck and you just saw a > ==71159== warning about a bad jump, it's probably your program's fault. > ==71159== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==71159== i.e. it's Valgrind's fault. If you think this is the case or > ==71159== you are not sure, please let us know and we'll try to fix it. > ==71159== Either way, Valgrind will now raise a SIGILL signal which will > ==71159== probably kill your program. > ==71159== > ==71159== Process terminating with default action of signal 4 (SIGILL) > ==71159== Illegal opcode at address 0x10438AB50 > ==71159== at 0x10438AB50: _dispatch_kq_init (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x1043888FB: _dispatch_client_callout (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x1043888B8: dispatch_once_f (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x10438AA90: _dispatch_kq_update (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x10438C0CD: _dispatch_kevent_resume (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x10438C03D: _dispatch_source_kevent_resume (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x10438BE85: _dispatch_source_kevent_register (in > /usr/lib/system/libdispatch.dylib) > ==71159== by 0x10439B651: _dispatch_queue_resume_finalize_activation > (in /usr/lib/system/libdispatch.dylib) > ==71159== by 0x1046DB3C0: _notify_lib_init (in > /usr/lib/system/libsystem_notify.dylib) > ==71159== by 0x1046DB9AB: notify_register_dispatch (in > /usr/lib/system/libsystem_notify.dylib) > ==71159== by 0x106E59916: CFUniCharMapTo (in /System/Library/Frameworks/ > CoreFoundation.framework/Versions/A/CoreFoundation) > ==71159== by 0x1043888FB: _dispatch_client_callout (in > /usr/lib/system/libdispatch.dylib) > ==71159== > ==71159== Events : Ir > ==71159== Collected : 260775396 > ==71159== > ==71159== I refs: 260,775,396 > The program has unexpectedly finished. > ** Process crashed ** > > 5. Looks like "UNKNOWN workq_ops option 128" is the problem, but there > isn't a VKI_WQOPS_* define for 128... > > |
|
From: John R. <jr...@bi...> - 2017-08-19 13:14:34
|
> 3. This is a Qt-based application
Find the smallest (shortest) executable which triggers the problem.
Does /bin/date work under your callgrind? Does a "null" Qt-based app suffer?
(Something like "BEGIN END;" or "{ }" with "no content": you get the idea.)
Post it here so that anyone can reproduce the problem.
--
|
|
From: IMoL <im...@gm...> - 2017-08-19 13:35:59
|
Thanks John.
"/bin/date" works (which is not surprising as I think workq_ops is related
to threads?)
- (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:
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
On Sat, Aug 19, 2017 at 9:14 AM, John Reiser <jr...@bi...> wrote:
> 3. This is a Qt-based application
>>
>
> Find the smallest (shortest) executable which triggers the problem.
> Does /bin/date work under your callgrind? Does a "null" Qt-based app
> suffer?
> (Something like "BEGIN END;" or "{ }" with "no content": you get the idea.)
> Post it here so that anyone can reproduce the problem.
>
> --
>
> ------------------------------------------------------------
> ------------------
> 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
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: John R. <jr...@bi...> - 2017-08-19 21:07:23
|
> - (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. -- |
|
From: IMoL <im...@gm...> - 2017-08-20 01:05:02
|
Done - thank you for looking into it John. https://bugs.kde.org/show_bug.cgi?id=383723 Please let me know if there's anything else I can do. - Andy On Sat, Aug 19, 2017 at 5:07 PM, John Reiser <jr...@bi...> wrote: > - (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/bu > g_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-a > nd-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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |