对于开发 FUSE 文件系统的人来说,这是一个永恒的问题。这个链接可能会有所帮助(在一个答案中整合起来实在是太多了)。解决方法包括及时更换 fusermount,以及(取决于)valgrind 的一些附加选项,以防止它跟踪子级。
事实上,如果你在 valgrind 下运行我的 FS,你会得到这个输出(是的,有足够多的人遇到这个问题,我实际上在启动时检测到了 valgrind 并显示了链接):
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 ....
最简单的做法是在以 root 身份运行的一次性 VM 中进行所有调试,您可以在其中放弃 setuid 位并完成它。确保您测试您的代码没有任何泄漏或违规,它很容易测试任何不使用 fuse 的链接库代码。将您的构建交给“valgrind-clean”,并注意您已经在文档中这样做了。
然后,取出一些位valgrind/valgrind.h
来检测它,并为那些继续运行它的人显示一条短消息。解决它的黑客需要根合作,坦率地说,在沙箱中也更容易完成。
在 setuid 位打开的情况下拒绝在 valgrind 下运行也很容易,如果他们真的想这样做,会显示一个有用的信息,让人们将其关闭。