Valgrind ignores any signals sent to any program I run, in OS X 10.10. To reproduce, run: valgrind sleep 60 And try sending ^C or SIGTERM or any signal (only SIGKILL works, which forces the process to die). When using "--trace-syscalls=yes --trace-signals=yes" and sending signals to the running process, nothing is shown and nothing happens.
I believe this has already been resolved in Valgrind SVN trunk. The version in Homebrew at the moment is fixed at a somewhat random SVN release a few months ago. Once the Valgrind 3.11 release is out, would expect they once again track formal releases. See below for output sending ^C on OS X 10.10 as at Valgrind r15614: =================== $ ./vg-in-place sleep 60 ==4018== Memcheck, a memory error detector ==4018== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==4018== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info ==4018== Command: sleep 60 ==4018== ^C==4018== ==4018== Process terminating with default action of signal 2 (SIGINT) ==4018== at 0x7FFF5FC19FDB: ImageLoaderMachOCompressed::doBindFastLazySymbol(unsigned int, ImageLoader::LinkContext const&, void (*)(), void (*)()) (in /usr/lib/dyld) ==4018== by 0x7FFF5FC0424D: dyld::fastBindLazySymbol(ImageLoader**, unsigned long) (in /usr/lib/dyld) ==4018== by 0x10013F3B9: dyld_stub_binder (in /usr/lib/system/libdyld.dylib) ==4018== by 0x100469007: ??? (in /usr/lib/system/libxpc.dylib) ==4018== by 0x1004449CB: _xpc_collect_environment (in /usr/lib/system/libxpc.dylib) ==4018== by 0x100441ACB: _libxpc_initializer (in /usr/lib/system/libxpc.dylib) ==4018== by 0x100014A94: libSystem_initializer (in /usr/lib/libSystem.B.dylib) ==4018== by 0x7FFF5FC12D0A: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==4018== by 0x7FFF5FC12E97: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==4018== by 0x7FFF5FC0F890: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==4018== by 0x7FFF5FC0F825: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==4018== by 0x7FFF5FC0F717: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==4018== ==4018== HEAP SUMMARY: ==4018== in use at exit: 30,435 bytes in 408 blocks ==4018== total heap usage: 506 allocs, 98 frees, 37,139 bytes allocated ==4018== ==4018== LEAK SUMMARY: ==4018== definitely lost: 0 bytes in 0 blocks ==4018== indirectly lost: 0 bytes in 0 blocks ==4018== possibly lost: 0 bytes in 0 blocks ==4018== still reachable: 0 bytes in 0 blocks ==4018== suppressed: 30,435 bytes in 408 blocks ==4018== ==4018== For counts of detected and suppressed errors, rerun with: -v ==4018== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ===================
No, I'm using the svn trunk; which is weird, as I see it seems to work for you... The fixed revision version available for homebrew does't work for Yosemite; if I try installing valgrind in OSX 10.10 (Yosemite) simply using "brew install valgrind", I get an error saying the bottle it's not available, that it's only available for Mavericks, so for installing it, I need to do it as "brew install --HEAD valgrind", which installs from the SVN trunk. I even manually checked out from the SVN repository, compiled it and tried it and it failed here. I tried in three different MacBook Pro running Yosemite. What else could be the problem then?
> I even manually checked out from the SVN repository, compiled it and tried it and it failed here. I tried in three different MacBook Pro running Yosemite. To be doubly sure, at this point you probably still had the Homebrew-derived valgrind install somewhere along your PATH. Did you run "sudo make install" within the folder you checkour out from the SVN repository? Alternatively ./vg-in-place sleep 60 within the checked out folder also ensures you are using the most recently compiled version from SVN.
Rhys, the only homebrew I ever installed was using `brew install --HEAD valgrind`, which installs valgrind from trunk source code. That homebrew command checks out trunk from SVN and installs it after compiling it. "Homebrew derived valgrind" bottle only works on Mavericks and I never installed it (I couldn't as it cannot be installed on Yosemite and on my his Mac I only ever had Yosemite installed). I will try deleting the whole `/usr/local/Cellar/valgrind` directory after doing brew uninstall valgrind to verify no `valgrind` command exists anywhere and also try the `vg-in-place` command and report back in a couple hours when I get to the office. But I'm fairly sure my current (non-working) `valgrind` command is updated with the source code in the SVN trunk. I don't know if any other installed or old library could also be causing this "no-signals" behavior... could that be plausible? Maybe it somehow clashes some other program or library.
Verified! The problem is there in r15619 here. Valgrind: r15619 System Version: OS X 10.10.5 (14F27) Kernel Version: Darwin 14.5.0 $ svn log | head ------------------------------------------------------------------------ r15619 | rhyskidd | 2015-09-03 06:31:58 -0500 (Thu, 03 Sep 2015) | 12 lines Fix UNKNOWN fcntl 97 on OS X 10.11 bz#351632 On OS X 10.11 (DP8) $ ./vg-in-place sleep 60 ==32048== Memcheck, a memory error detector ==32048== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==32048== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info ==32048== Command: sleep 60 ==32048== ^C^C^C^C^C^C^C^C
I just tried this again in a whole other different laptop and still got the same problem. I got the code from svn://svn.valgrind.org/valgrind/trunk After `valgrind sleep 60` and then ^C it still doesn't exit. Any signals are ignored, only `kill -9` works. This makes valgrind pretty hard to work with, I tried figuring out where the problem might be, but I don't know valgrind internals and I couldn't figure it out :/ Rhys Kidd, where are you testing valgrind? I'm using trunk from svn (positively sure) I'm using OS X 10.10.5 in a MacBook Pro Core i7 (Early 2011) and I also tried it in several MacBook Pro (Mid 2014) it didn't work anywhere I tested.
Can't easily try this on 10.10. I'll have a go with a 10.13 VM.
Still hanging. Need to look at is_signal_from_kernel to see if anything has changed.
This now works on macOS 10.14. Valgrind wasn't handling signal masks properly. Code from Louis Brunner fixed that (Greg Parker left comments saying what needed to be done). Running the "sleep 60" test. ==11841== Memcheck, a memory error detector ==11841== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==11841== Using Valgrind-3.27.0.GIT and LibVEX; rerun with -h for copyright info ==11841== Command: sleep 60 ==11841== ^C==11841== ==11841== Process terminating with default action of signal 2 (SIGINT) ==11841== at 0x1004F3F32: __semwait_signal (in /usr/lib/system/libsystem_kernel.dylib) ==11841== by 0x100000E72: _mh_execute_header (in /bin/sleep) ==11841== by 0x1002633D4: start (in /usr/lib/system/libdyld.dylib) ==11841== by 0x1: ??? ==11841== by 0x1048CFCFB: ??? ==11841== by 0x1048CFD01: ??? ==11841== ==11841== HEAP SUMMARY: ==11841== in use at exit: 18,514 bytes in 153 blocks ==11841== total heap usage: 174 allocs, 21 frees, 26,962 bytes allocated ==11841== ==11841== LEAK SUMMARY: ==11841== definitely lost: 0 bytes in 0 blocks ==11841== indirectly lost: 0 bytes in 0 blocks ==11841== possibly lost: 0 bytes in 0 blocks ==11841== still reachable: 0 bytes in 0 blocks ==11841== suppressed: 18,514 bytes in 153 blocks ==11841== ==11841== For lists of detected and suppressed errors, rerun with: -s ==11841== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 398 from 10)