If I do: valgrind /Users/sean/Desktop/Valgrind\ Test/build/Debug/Valgrind\ Test.app (Note the spaces in the path.) It complains: --7764-- run: /usr/bin/dsymutil /Users/sean/Desktop/Valgrind Test/build/ Debug/Valgrind Test.app/Contents/MacOS/Valgrind Test error: unable to open executable '/Users/sean/Desktop/Valgrind' and then I get backtraces like: ... ==7655== by 0xD451D7: NSApplicationMain (in /System/Library/ Frameworks/AppKit.framework/Versions/C/AppKit) ==7655== by 0x1FFB: main (in /Users/sean/Desktop/ValgrindTest/build/ Debug/ValgrindTest.app/Contents/MacOS/ValgrindTest) Note that filename and line number are missing for main(). Using --dsymutil=yes does not help. Removing all spaces from paths works around this.
Duplicate of 205093? Or, at least, related to 205093?
Probably related, but can Guy confirm if this is still an issue with the most recent Valgrind release or Git version? Valgrind 3.5.0 is rather old now, having been released in August 2009.
$ valgrind --version valgrind-3.13.0 $ valgrind --leak-check=full /tmp/foo\ bar/foo\ bar ==98088== Memcheck, a memory error detector ==98088== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==98088== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==98088== Command: /tmp/foo\ bar/foo\ bar ==98088== --98088-- run: /usr/bin/dsymutil "/tmp/foo bar/foo bar" ... ==98088== 2,048 bytes in 1 blocks are definitely lost in loss record 37 of 42 ==98088== at 0x100096861: malloc (vg_replace_malloc.c:302) ==98088== by 0x100000F6A: main (in /tmp/foo bar/foo bar) (deliberately leaked in my small test program).