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.