Bug 352021

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.