I am running valgrind as follows:-
/usr/local/bin/valgrind "process_name"
After excecution its giving me following error
==21731==
==21731== Warning: Can't execute setuid/setgid executable:
==21731== Possible workaround: remove --trace-children=yes, if in effect
==21731==
valgrind: "process name": Permission denied
My valgrind permission is as follows :- -r-sr-xr-x /usr/local/bin/valgrind
My process permission is as follows:- -r-sr-xr-x "process_name"
Platform : Linux VMLINUX3 2.6.9-78.0.22.ELsmp(RHEL)
Valgrind version: valgrind-3.5.0
Any help on this will be appreciated
This is a perpetual problem for people who develop FUSE file systems. This link may help (it's quite literally too much to consolidate in a single answer). The work-around involves a just-in-time replacement of fusermount, and (depending), some additional options to valgrind to prevent it from tracing children.
In fact, if you run my FS under valgrind, you get this output (yes, enough people had that problem that I actually detected valgrind on start up and displayed the link):
root@tower:~ # valgrind xsfs /xs
==9479== Memcheck, a memory error detector.
==9479== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==9479== Using LibVEX rev 1884, a library for dynamic binary translation.
==9479== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==9479== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==9479== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==9479== For more details, rerun with: -v
==9479==
******** Valgrind has been detected by xsfs
******** If you have difficulties getting xsfs to work under Valgrind,
******** see the following thread:
******** http://www.nabble.com/valgrind-and-fuse-file-systems-td13112112.html
******** Sleeping for 5 seconds so this doesn't fly by ....
The easiest thing to do is all of your debugging in a disposable VM running as root, where you can just ditch the setuid bit, and be done with it. Make sure you test your code to not have any leaks or violations, its easy enough to test any linked library code not using fuse. Hand your build off 'valgrind-clean' and note that you've done so in the documentation.
Then, grab some bits out of valgrind/valgrind.h to detect it, and show a short message for those that go ahead and run it anyway. Hacks to work around it require root cooperation, and quite frankly, are much easier done in a sandbox just as well.
It's also easy enough to refuse to run under valgrind with the setuid bit on, showing a helpful message for people to turn it off if they really want to do it.