Here are the notes I have about running Fuse with Valgrind...
* Problem
By default, Fuse and Valgrind do not play nice together, making
debugging memory errors in <myfs> a bit of a hassle.
See the links below for a little bit of background.
>From
http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/4095/focus=4114.
>> [*] I had been having problems with valgrind and permission problems.
>> What works is to run valgrind as root, and chmod 755
>> /usr/bin/fusermount.
>
>Yes, stupid valgrind. My workaround is to replace /usr/bin/fusermount
>with a shell script which just execs /usr/bin/fusermount.real.
>Miklos
Also, from
http://osdir.com/ml/file-systems.fuse.devel/2006-01/msg00093.html,
it appears the problem is related to setuid programs. The Fuse mount
utility, fusermount, is a setuid program.
Finally, a link in the previous message
http://bugs.kde.org/show_bug.cgi?id=119404 further explains that
setuid programs can be run by valgrind, but they cannot be traced.
* Solution
Here is one possible workaround the problem.
As root,
$ cd /usr/bin
$ if [[ -e fusermount ]]; then mv fusermount fusermount.real; fi
$ touch fusermount
$ chown root.fuse fusermount
$ chmod ug+x fusermount
$ echo '#!/bin/sh' >> fusermount
$ echo 'exec /usr/bin/fusermount.real $@' >> fusermount
or depending on the path of fusermount
$ echo 'exec /bin/fusermount $@' >> fusermount
The other key point is to ensure that the setuid fusermount is not
traced. Thus valgrind should be called as
$ valgrind --tool=memcheck --trace-children=no ... myfs ...
Finally, to work with Valgrind, <myfs> should be run in the
foreground. To keep <myfs> from daemonizing, include the -d (debug)
option.
Putting it all together, one can run <myfs> under Valgrind with a command like
$ valgrind --tool=memcheck --trace-children=no --leak-check=full
--show-reachable=yes --max-stackframe=3000000 -v myfs -d /mnt/myfs ...
On Wed, Jun 25, 2008 at 2:12 PM, kuba <
kubagruszka@...> wrote:
> Hi all,
>
> Is it possible to determine memory leaks using valgrind on fuse filesystem? Or
> maybe you have any other suggestions ? I tried to use Garbage Collector for C,
> beacuse I read that it can produce statistics on program termination but It
> didn't worke out.
> I ran my filesystem with valgrind by it didn't produce proper stats at the end?
> i.e.
> ==18349== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
>
> wasn't true because I ran in my program at least two allocs.
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
http://sourceforge.net/services/buy/index.php> _______________________________________________
> fuse-devel mailing list
>
fuse-devel@...
>
https://lists.sourceforge.net/lists/listinfo/fuse-devel>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel