Bug 207613

Summary: memcheck fails to handle paths with spaces on Mac; line numbers lost as result
Product: [Developer tools] valgrind Reporter: Sean <cwatson>
Component: memcheckAssignee: Rhys Kidd <rhyskidd>
Status: REPORTED ---    
Severity: normal CC: gharris, njn, pjfloyd, rhyskidd
Priority: NOR    
Version: 3.5.0   
Target Milestone: blocking3.5.1   
Platform: Unlisted Binaries   
OS: macOS   
See Also: https://bugs.kde.org/show_bug.cgi?id=205093
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Sean 2009-09-16 20:53:15 UTC 
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.
Comment 1 Guy Harris 2017-10-14 18:45:17 UTC 
Duplicate of 205093?  Or, at least, related to 205093?
Comment 2 Rhys Kidd 2017-10-15 17:25:13 UTC 
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.
Comment 3 Guy Harris 2017-10-15 19:36:51 UTC 
$ 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).