2.6.1. 工具选择选项

--tool=<toolname> [default: memcheck]

运行称为的Valgrind工具toolname，例如memcheck，cachegrind，callgrind，helgrind，drd，massif，dhat，bouchey，none，exp-sgcheck，exp-bbv等。

2.6.2 ..基本选项

-h --help

对核心和所选工具的所有选项显示帮助。如果重复该选项，则等同于给出 --help-debug。

--help-debug

与相同--help，但还列出了调试选项，通常仅对Valgrind的开发人员有用。

--version

显示Valgrind内核的版本号。工具可以具有自己的版本号。有一个适当的方案可以确保仅在已知核心版本可以使用这些工具时才执行工具。这样做是为了最大程度地减少由于工具与核心版本不兼容而引起的奇怪问题的机会。

-q， --quiet

以静默方式运行，并且仅显示错误消息。如果您正在运行回归测试或具有其他一些自动化测试机制，则很有用。

-v， --verbose

更加冗长。提供有关程序各个方面的额外信息，例如：加载的共享对象，使用的抑制，检测和执行引擎的进度以及有关异常行为的警告。重复该选项会增加详细程度。

--trace-children=<yes|no> [default: no]

启用后，Valgrind将跟踪通过exec系统调用启动的子流程。这对于多进程程序是必需的。

请注意，Valgrind确实会跟踪到a的子项 fork（由于fork创建了相同的进程副本，因此很难 做到这一点），因此此选项的名称可谓是错误的。但是，大多数 fork通话对象都会立即拨打电话exec 。

--trace-children-skip=patt1,patt2,...

仅当--trace-children=yes指定时，此选项才有效 。它允许一些孩子被跳过。该选项采用逗号分隔的模式列表来表示Valgrind不应跟踪的子可执行文件的名称。模式可能包含具有通常含义的元字符? 和*。

这对于从Valgrind上运行的进程树中删除无用的分支很有用。但是，使用时应小心。当Valgrind跳过对可执行文件的跟踪时，它不仅跳过对可执行文件的跟踪，而且还跳过对可执行文件的任何子进程的跟踪。换句话说，该标志不仅会导致跟踪在指定的可执行文件处停止，还会跳过对植根于任何指定的可执行文件的整个进程子树的跟踪。

--trace-children-skip-by-arg=patt1,patt2,...

这与相同 --trace-children-skip，但有一个区别：是否检查子进程是通过检查子进程的参数而不是其可执行文件的名称来决定的。

--child-silent-after-fork=<yes|no> [default: no]

启用后，Valgrind将不会显示由fork调用导致的子进程的任何调试或日志记录输出。在处理创建子进程时，这可以使输出的混乱程度降低（尽管会产生更多误导）。与结合使用时特别有用--trace-children=。如果您请求XML输出（--xml=yes），也强烈建议使用此选项，因为否则，子级和父级的XML可能会混合在一起，这通常使它无用。

--vgdb=<no|yes|full> [default: yes]

指定--vgdb=yes或时，Valgrind将提供“ gdbserver”功能 --vgdb=full。这使外部GNU GDB调试器在Valgrind上运行时可以控制和调试程序。 --vgdb=full会产生巨大的性能开销，但会提供更精确的断点和观察点。有关详细说明，请参见使用Valgrind的gdbserver和GDB调试程序。

如果启用了嵌入式gdbserver，但当前未使用任何gdb，则vgdb 命令行实用程序可以从外壳向Valgrind发送“监视命令”。Valgrind核心提供了一组 Valgrind监视命令。工具可以选择提供工具特定的监视命令，这些命令记录在工具特定的章节中。

--vgdb-error=<number> [default: 999999999]

当通过--vgdb=yes或启用Valgrind gdbserver时，请使用此选项 --vgdb=full。报告错误的工具将number在冻结程序并等待您与GDB连接之前等待报告错误。因此，零值将导致gdbserver在执行程序之前启动。这通常用于在执行之前插入GDB断点，还可以与不报告错误的工具（例如Massif）一起使用。

--vgdb-stop-at=<set> [default: none]

当通过--vgdb=yes或启用Valgrind gdbserver时，请使用此选项 --vgdb=full。--vgdb-error报告每个错误后，将为每个错误调用Valgrind gdbserver 。您还可以要求通过以下方式之一为其他事件调用Valgrind gdbserver：

--track-fds=<yes|no> [default: no]

启用后，Valgrind将通过gdbserver monitor命令在退出或请求时打印出打开文件描述符的列表v.info open_fds。与每个文件描述符一起打印的是文件打开位置以及与文件描述符有关的任何详细信息（例如文件名或套接字详细信息）的堆栈回溯。

--time-stamp=<yes|no> [default: no]

启用后，每条消息之前都会显示自启动以来经过的挂钟时间，以天，小时，分钟，秒和毫秒表示。

--log-fd=<number> [default: 2, stderr]

指定Valgrind应该将其所有消息发送到指定的文件描述符。默认值2是标准错误通道（stderr）。请注意，这可能会干扰客户端自己使用stderr，因为Valgrind的输出将与客户端发送给stderr的任何输出交错。

--log-file=<filename>

指定Valgrind应该将其所有消息发送到指定文件。如果文件名为空，则会导致中止。文件名中可以​​使用三种特殊格式的说明符。

%p被替换为当前的进程ID。这对于调用多个进程的程序非常有用。警告：如果您使用--trace-children=yes并且您的程序调用了多个进程，或者您的程序派生后没有调用exec，并且您不使用此说明符（或%q下面的说明符），则所有这些进程的Valgrind输出将进入一个文件，可能会混杂可能不完整。注意：如果程序在之后派生并调用exec，则从fork和exec之间的时间段的子代的Valgrind输出将丢失。幸运的是，对于大多数程序而言，这种差距确实很小。和现代程序posix_spawn 仍然使用。

%n替换为该过程唯一的文件序号。这对于从相同文件名模板生成多个文件的进程很有用。

%q{FOO}被环境变量的内容替换FOO。如果 {FOO}零件格式不正确，则会导致中止。该说明符很少需要，但在某些情况下（例如，运行MPI程序时）非常有用。这个想法是，您指定一个变量，该变量将为作业中的每个过程设置不同的变量，例如，BPROC_RANK或在MPI设置中适用的任何变量。如果未设置命名的环境变量，则会导致中止。请注意，在某些外壳程序中，可能需要使用 {和}字符加上反斜杠来转义。

%%被替换为%。

如果an %后面跟随任何其他字符，则将导致中止。

如果文件名指定了相对文件名，则将其放在程序的初始工作目录中：这是程序在fork之后或exec之后开始执行的当前目录。如果它指定了绝对文件名（即以“ /”开头），则将其放置在那里。

--log-socket=<ip-address:port-number>

指定Valgrind应该将其所有消息发送到指定IP地址的指定端口。该端口可以省略，在这种情况下，使用端口1500。如果无法与指定的套接字建立连接，则Valgrind会退回将输出写入标准错误（stderr）。该选项旨在与valgrind-listener程序结合使用 。有关更多详细信息，请参见 手册中的注释。

2.6.3。与错误相关的选项

--xml=<yes|no> [default: no]

启用后，输出的重要部分（例如，工具错误消息）将采用XML格式，而不是纯文本。此外，XML输出将被发送到与纯文本输出不同的输出通道。因此，还必须使用的一个 --xml-fd，--xml-file或 --xml-socket到指定的XML将被发送。

不太重要的消息将仍然以纯文本被打印，但是，因为XML输出和明文输出被发送到不同的输出信道（纯文本输出的目的地仍然由控制--log-fd，--log-file 和--log-socket）这不应引起问题。

此选项旨在使使用Valgrind的输出作为输入的工具（例如GUI前端）的工作更轻松。当前，此选项可与Memcheck，Helgrind，DRD和SGcheck一起使用。docs/internals/xml-output-protocol4.txt 对于Valgrind 3.5.0或更高版本，在源树的文件中指定了输出格式 。

在请求XML输出时，建议GUI通过的选项是：--xml=yes启用XML输出， --xml-file将XML输出发送到（可能是GUI选择的）文件，--log-file将纯文本输出发送到第二个GUI选择的文件， --child-silent-after-fork=yes，并将 -q纯文本输出限制为Valgrind自身创建的严重错误消息。例如，无法读取指定的禁止文件将被视为严重错误消息。这样，为了成功运行，文本输出文件将为空。但是，如果不为空，则它将包含GUI用户应该意识到的重要信息。

--xml-fd=<number> [default: -1, disabled]

指定Valgrind应该将其XML输出发送到指定的文件描述符。它必须与结合使用 --xml=yes。

--xml-file=<filename>

指定Valgrind应该将其XML输出发送到指定文件。它必须与结合使用 --xml=yes。文件名中出现的任何%p或 %q序列都以与完全相同的方式扩展--log-file。有关详细信息，请参见 --log-file的描述。

--xml-socket=<ip-address:port-number>

指定Valgrind应该在指定的IP地址将其XML输出发送到指定的端口。它必须与结合使用--xml=yes。参数的形式与所使用的形式相同--log-socket。有关--log-socket 更多详细信息，请参见的描述。

--xml-user-comment=<string>

在XML输出的开头嵌入一个额外的用户注释字符串。仅在--xml=yes指定时有效；否则忽略。

--demangle=<yes|no> [default: yes]

启用/禁用C ++名称的自动拆线（解码）。默认启用。启用后，Valgrind将尝试将编码的C ++名称转换回接近原始名称的名称。分解器处理由g ++版本2.X，3.X和4.X破坏的符号。

关于分解的一个重要事实是，抑制文件中提到的函数名称应采用整齐的形式。在搜索适用的抑制时，Valgrind不会对函数名称进行拆散，因为否则将使抑制文件的内容取决于Valgrind的拆解机制的状态，并且还会减慢抑制匹配的速度。

--num-callers=<number> [default: 12]

指定用于标识程序位置的堆栈跟踪中显示的最大条目数。请注意，错误仅通过使用函数的前四个位置（当前函数中的位置以及它的三个直接调用方的位置）来实现。因此，这不会影响报告的错误总数。

最大值为500。请注意，较高的设置将使Valgrind的运行速度稍慢一些，并占用更多的内存，但是在处理具有深层嵌套调用链的程序时可能很有用。

--unw-stack-scan-thresh=<number> [default: 0] ， --unw-stack-scan-frames=<number> [default: 5]

堆栈扫描支持仅在ARM目标上可用。

这些标志通过堆栈扫描启用和控制堆栈展开。当正常的堆栈退卷机制（使用Dwarf CFI记录和跟随帧指针）失败时，堆栈扫描可能能够恢复堆栈跟踪。

请注意，堆栈扫描是一种不精确的启发式机制，可能会产生非常误导的结果，或者根本不会给出任何结果。它仅应在正常展开失败时的紧急情况下使用，但是具有堆栈跟踪很重要。

堆栈扫描是一种简单的技术：展开器从堆栈中读取字，然后通过检查它们是否指向ARM或Thumb调用指令之后，尝试猜测其中哪些可能是返回地址。如果是这样，则将单词添加到回溯中。

当函数调用返回而暴露其返回地址并调用新函数时，会发生主要危险，但是新函数不会覆盖旧地址。结果是回溯可能包含已经返回的函数的条目，因此非常混乱。

此实现的第二个限制是它将仅扫描包含起始堆栈指针的页面（通常为4KB）。如果堆栈帧很大，则可能导致迹线中仅出现很少（甚至没有任何）。另外，如果您很不幸，并且在其包含页面的末尾附近有一个初始堆栈指针，则扫描可能会丢失所有有趣的帧。

默认情况下，堆栈扫描是禁用的。正常的用例是在堆栈跟踪非常短时要求它。因此，要启用它，请使用--unw-stack-scan-thresh=number。这要求Valgrind尝试使用堆栈扫描来“扩展”包含少于number帧的堆栈跟踪。

如果确实进行了堆栈扫描，则最多只会生成所指定的帧数--unw-stack-scan-frames。通常，堆栈扫描会生成大量垃圾条目，因此默认情况下将此值设置为较低的值（5）。在任何情况下，都--num-callers不会创建大于所指定值的堆栈跟踪。

--error-limit=<yes|no> [default: yes]

启用后，Valgrind将在总共看到10,000,000个或1,000个不同的错误后停止报告错误。这是为了防止错误跟踪机制在具有许多错误的程序中成为巨大的性能开销。

--error-exitcode=<number> [default: 0]

指定一个替代退出代码，如果Valgrind报告运行中有任何错误，则返回该退出代码。当设置为默认值（零）时，Valgrind的返回值将始终是被模拟过程的返回值。当设置为非零值时，如果Valgrind检测到任何错误，则返回该值。这对于将Valgrind用作自动化测试套件的一部分很有用，因为通过检查返回码，可以很容易地检测Valgrind报告了错误的测试用例。

--exit-on-first-error=<yes|no> [default: no]

如果启用此选项，Valgrind将在第一个错误时退出。必须使用--error-exitcodeoption 定义非零退出值 。如果您正在运行回归测试或具有其他一些自动化测试机制，则很有用。

--error-markers=<begin>,<end> [default: none]

当错误以纯文本格式输出（即未使用XML）时， --error-markers指示在每个错误之前（之后）输出包含begin（end）字符串的行。

这样的标记行有助于在包含与程序输出混合的valgrind错误的输出文件中搜索错误和/或提取错误。

请注意，可以使用空标记。因此，仅可以使用开始（或结束）标记。

--show-error-list=no|yes [default: no]

如果启用此选项，则对于报告错误的工具，valgrind将在出口处显示检测到的错误列表和已使用的抑制列表。

请注意，在详细程度2和更高的级别，除非--show-error-list=no选中，否则valgrind会自动显示检测到的错误列表和退出时使用的抑制列表 。

-s

指定-s等同于 --show-error-list=yes。

--sigill-diagnostics=<yes|no> [default: yes]

启用/禁用非法指令诊断的打印。默认情况下启用，但--quiet给定时默认为禁用 。通过提供此选项，始终可以显式覆盖默认值。

启用后，在程序收到SIGILL信号之前，每当遇到Valgrind无法解码或翻译的指令时，将打印警告消息以及一些诊断信息。通常，非法指令表示程序中存在错误或对Valgrind中的特定指令缺少支持。但是某些程序确实故意执行一条可能丢失的指令，并捕获SIGILL信号以检测处理器功能。使用此标志可以避免在这种情况下可能获得的诊断输出。

--keep-debuginfo=<yes|no> [default: no]

启用后，保留（“归档”）符号和所有其他debuginfo来保存已卸载的代码。这允许保存的堆栈跟踪信息包括已被dlclose（或类似）的代码的文件/行信息。请注意这一点，因为它可能导致重复加载和卸载共享对象的程序无限制地使用内存。

某些工具和某些功能仅对存档的调试信息提供有限的支持。Memcheck完全支持它。通常，报告错误的工具可以使用存档的调试信息来显示错误堆栈跟踪。已知的限制是：Helgrind过去对竞争条件的访问堆栈跟踪是不使用存档的调试信息。Massif（更常见的是xtree Massif输出格式）不使用存档的调试信息。仅Memcheck已通过进行（某种程度上）测试--keep-debuginfo=yes，因此其他工具可能具有未知的限制。

--show-below-main=<yes|no> [default: no]

默认情况下，错误的堆栈跟踪不显示下面显示的任何函数，main因为在大多数情况下，它是不感兴趣的C库内容和/或gobbledygook。或者，如果main堆栈跟踪中不存在，则堆栈跟踪将不显示任何main类似于glibc之类的函数 __libc_start_main。此外，如果main在跟踪中存在类似函数，则将 它们标准化为(below main)，以使输出更具确定性。

如果启用此选项，将显示所有堆栈跟踪条目，并且main类似函数将不被标准化。

--fullpath-after=<string> [default: don't show source paths]

默认情况下，Valgrind仅显示堆栈跟踪中的文件名，而不显示源文件的完整路径。在源位于多个不同目录的大型项目中使用Valgrind时，这可能会带来不便。 --fullpath-after为该问题提供了灵活的解决方案。使用此选项时，将显示每个源文件的路径，并具有以下所有重要的警告：如果string在路径中找到该路径，则将string省略直至（包括）的路径，否则该路径将显示为未修改。请注意，string不需要将其作为路径的前缀。

例如，考虑一个名为的文件 /home/janedoe/blah/src/foo/bar/xyzzy.c。指定--fullpath-after=/home/janedoe/blah/src/ 将使Valgrind将名称显示为foo/bar/xyzzy.c。

因为不需要将字符串作为前缀，所以 --fullpath-after=src/将产生相同的输出。当路径包含任意机器生成的字符时，这很有用。例如，所述路径 /my/build/dir/C32A1B47/blah/src/foo/xyzzy 可以被修剪至foo/xyzzy 使用 --fullpath-after=/blah/src/。

如果您只想查看完整路径，只需指定一个空字符串：--fullpath-after=。这不是特例，只是上述规则的逻辑结果。

最后，您可以使用--fullpath-after 多次。它的任何出现都会导致Valgrind切换为生成完整路径并应用上述过滤规则。--fullpath-after按照指定的顺序，将每个产生的路径与所有-specified字符串进行比较。如上所述，第一个匹配的字符串将导致路径被截断。如果没有匹配项，则显示完整路径。从多个不相关的目录中提取源代码时，这有助于切掉前缀。

--extra-debuginfo-path=<path> [default: undefined and unused]

默认情况下，Valgrind在几个众所周知的路径中搜索调试对象，例如/usr/lib/debug/。

但是，在某些情况下，您可能希望将调试对象放置在任意位置，例如在本地存储空间有限的移动设备上运行Valgrind时使用外部存储空间。另一个示例可能是您无权在运行Valgrind的系统上安装调试对象程序包的情况。

在这些情况下，您可以通过指定来提供绝对路径，作为Valgrind搜索调试对象的最终位置 --extra-debuginfo-path=/path/to/debug/objects。给定的路径将放在搜索对象的绝对路径名之前。例如，如果Valgrind在为其寻找debuginfo /w/x/y/zz.so 并为其--extra-debuginfo-path=/a/b/c指定了调试信息，它将在处寻找一个调试对象 /a/b/c/w/x/y/zz.so。

该标志只能指定一次。如果多次指定，则仅保留最后一个实例。

--debuginfo-server=ipaddr:port [default: undefined and unused]

这是3.9.0版中引入的实验性新功能。

在某些情况下，从存储在不同计算机上的对象读取debuginfo可能很方便。使用此标志，如果Valgrind 在本地文件系统中找不到debuginfo对象，它将查询ipaddr在port 上侦听的debuginfo服务器port。

debuginfo服务器必须在port上接受TCP连接port。debuginfo服务器包含在源文件中auxprogs/valgrind-di-server.c。它将仅从其启动目录开始服务。 port如果未指定，则在客户端和服务器中默认为1500。

如果Valgrind /w/x/y/zz.so通过使用debuginfo服务器查找 debuginfo，它将剥离路径名组件，仅zz.so在服务器上请求。反过来，它将仅在其当前工作目录中查找匹配的debuginfo对象。

根据Valgrind的要求，debuginfo数据以小片段（8 KB）的形式传输。每个块都使用LZO压缩以减少传输时间。已针对单级802.11g（WiFi）网络链接对实现进行了优化，以实现最佳性能。

请注意，即使使用debuginfo服务器，也要使用GNU debuglink CRC方案检查匹配的主要对象与调试对象。要禁用这种检查，还需要指定 --allow-mismatched-debuginfo=yes。

默认情况下，Valgrind构建系统将为valgrind-di-server目标平台构建，这几乎肯定不是您想要的。到目前为止，我们还无法找到如何获取automake / autoconf来为构建平台进行构建。如果要使用它，则必须使用顶部显示的命令来手工重新编译它auxprogs/valgrind-di-server.c。

--allow-mismatched-debuginfo=no|yes [no]

当从单独的debuginfo对象读取debuginfo时，默认情况下，Valgrind将使用GNU debuglink机制检查main和debuginfo对象是否匹配。这保证了它不会从过期的debuginfo对象中读取debuginfo，并且还确保Valgrind不会因不匹配而崩溃。

可以使用覆盖此检查 --allow-mismatched-debuginfo=yes。当debuginfo和main对象没有以正确的方式拆分时，这可能很有用。但是，使用此方法时要小心：它会禁用所有一致性检查，并且已经观察到当主对象和debuginfo对象不匹配时，Valgrind会崩溃。

--suppressions=<filename> [default: $PREFIX/lib/valgrind/default.supp]

指定一个额外的文件，从该文件中读取要抑制的错误的描述。您最多可以使用100个额外的禁止文件。

--gen-suppressions=<yes|no|all> [default: no]

设置yes为时，Valgrind将在显示每个错误之后暂停并打印以下行：

按Ret或N Ret或 n Ret导致Valgrind继续执行，而不会输出对该错误的抑制。

按下Y Ret或 y Ret使Valgrind为该错误写一个抑制符。如果您以后不想再听到该错误，则可以将其剪切并粘贴到抑制文件中。

设置all为时，Valgrind将为每个报告的错误打印抑制信息，而无需查询用户。

该选项在C ++程序中特别有用，因为它可以根据需要打印出带有乱码的名称。

请注意，打印的抑制内容尽可能具体。您可能希望通过在函数名称中添加通配符并使用帧级通配符来实现相似的功能。通配符功能强大而又灵活，并且通过一些仔细的编辑，您可能仅需少量抑制就可以抑制整个相关错误家族。

有时，相同的抑制可以抑制两个不同的错误，在这种情况下，Valgrind会多次输出抑制，但是您只需要在抑制文件中有一个副本（但是有多个副本不会造成问题）。另外，抑制名称为 <insert a suppression name here>；名称实际上并不重要，它仅与-v打印所有已使用的抑制记录的选项一起使用。

--input-fd=<number> [default: 0, stdin]

使用时 --gen-suppressions=yes，Valgrind将会停止，以便在发生每个错误时读取您的键盘输入。默认情况下，它从标准输入（stdin）读取，这对于关闭stdin的程序来说是有问题的。此选项允许您指定从中读取输入的备用文件描述符。

--dsymutil=no|yes [yes]

仅当在Mac OS X上运行Valgrind时，此选项才相关。

Mac OS X使用延迟的调试信息（debuginfo）链接方案。将包含debuginfo的目标文件链接到.dylib或可执行文件时，debuginfo不会复制到最终文件中。相反，必须通过dsymutil在可执行文件或上运行系统提供的实用程序来手动链接debuginfo .dylib。结果组合的debuginfo放在可执行文件或旁边的目录中.dylib，但带有扩展名.dSYM。

使用--dsymutil=no，Valgrind将检测 .dSYM目录丢失或存在的情况，但似乎与相关的可执行文件或不匹配的情况.dylib，很可能是因为该目录已过期。在这种情况下，Valgrind将打印警告消息，但不采取进一步措施。

--dsymutil=yes在这种情况下，使用Valgrind将自动运行dsymutil以使debuginfo保持最新状态。出于所有实际目的，如果您始终使用--dsymutil=yes，则不再需要dsymutil手动运行或作为应用程序的构建系统的一部分运行，因为Valgrind会根据需要运行它。

Valgrind的不会尝试运行dsymutil任何可执行文件或库 /usr/， /bin/， /sbin/， /opt/， /sw/， /System/， /Library/或 /Applications/ 因为dsymutil总是会失败在这种情况下。它之所以失败，不仅是因为此类预安装系统组件的debuginfo在任何地方都不可用，还因为它要求在这些目录中具有写权限。

使用时要小心--dsymutil=yes，因为它将导致.dSYM 静默删除现有目录并重新创建。另请注意， dsymutil速度相当缓慢，有时速度过快。

--max-stackframe=<number> [default: 2000000]

堆叠框架的最大尺寸。如果堆栈指针的移动量超过此数量，则Valgrind将假定程序正在切换到其他堆栈。

如果您的程序具有大的堆栈分配数组，则可能需要使用此选项。Valgrind跟踪程序的堆栈指针。如果它的变化量大于阈值量，则Valgrind会假定您的程序正在切换到其他堆栈，并且Memcheck的行为与更改小于阈值的堆栈指针的行为不同。通常，这种启发式方法效果很好。但是，如果您的程序在堆栈上分配了大型结构，则该启发式将被愚弄，Memcheck随后将报告大量无效的堆栈访问。此选项使您可以将阈值更改为其他值。

仅当Valgrind的调试输出指导您这样做时，才应考虑使用此选项。在这种情况下，它将告诉您应该指定的新阈值。

通常，在堆栈上分配大型结构是一个坏主意，因为您很容易用完堆栈空间，尤其是在内存有限或希望支持大量线程且每个堆栈较小的系统上，并且因为错误由Memcheck执行的检查对堆分配的数据比对堆栈分配的数据更有效。如果必须使用此选项，则可能希望考虑重写代码以在堆而不是堆栈上进行分配。

--main-stacksize=<number> [default: use current 'ulimit' value]

指定主线程堆栈的大小。

为了简化其内存管理，Valgrind在启动时为主线程的堆栈保留了所有必需的空间。这意味着它需要在启动时知道所需的堆栈大小。

默认情况下，Valgrind使用当前的“ ulimit”值作为堆栈大小，或16 MB，以较小者为准。在许多情况下，堆栈大小在8到16 MB之间，对于大多数应用程序几乎不会溢出。

如果需要更大的总堆栈大小，请使用--main-stacksize来指定它。仅将其设置为所需的大小，因为保留的空间远远超出所需的空间（即，超出所需的数百兆字节）会限制Valgrind的内存分配器，并可能减少Valgrind可以使用的内存总量。这仅在32位计算机上才真正有意义。

在Linux上，您可能需要最大2GB的堆栈。如果无法分配堆栈，Valgrind将停止并显示一条诊断消息。

--main-stacksize仅影响程序初始线程的堆栈大小。它与线程堆栈的大小无关，因为Valgrind不会分配这些线程。

您可能需要同时使用--main-stacksize 和--max-stackframe同时使用。重要的是要了解--main-stacksize设置最大总堆栈大小，同时--max-stackframe指定任何一个堆栈帧的最大大小。您将必须--main-stacksize自己计算出价值（通常，如果应用程序存在段错误）。但是--max-stackframe如果需要，Valgrind会告诉您所需的尺寸。

如在的描述中进一步讨论的--max-stackframe，对大堆栈的要求是潜在的可移植性问题的标志。最好建议将所有大数据放在堆分配的内存中。

--max-threads=<number> [default: 500]

默认情况下，Valgrind最多可以处理500个线程。有时，该数字太小。使用此选项可以提供不同的限制。例如 --max-threads=3000。

2.6.4。与malloc相关的选项

--alignment=<number> [default: 8 or 16, depending on the platform]

默认情况下，Valgrind的malloc， realloc等返回一个起始地址为8字节对齐或16字节对齐的块（该值取决于平台并与平台默认值匹配）。此选项使您可以指定其他对齐方式。提供的值必须大于或等于默认值，小于或等于4096，并且必须是2的幂。

--redzone-size=<number> [default: depends on the tool]

Valgrind malloc, realloc,等在运行程序分配的每个堆块之前和之后添加填充块。这种填充块称为Redzone。Redzone大小的默认值取决于工具。例如，Memcheck在客户端分配的每个块之前和之后添加并保护至少16个字节。这样，它就可以检测最多16个字节的块下溢或溢出。

增加红色区域的大小可以检测较大距离的超限，但可以增加Valgrind使用的内存量。减小Redzone大小将减少Valgrind所需的内存，但也会减少检测到超限/不足的机会，因此不建议这样做。

--xtree-memory=none|allocs|full [none]

替换Valgrind malloc, realloc,等的工具可以有选择地生成一个执行树，详细说明哪段代码负责堆内存的使用。有关执行树 的详细说明，请参见执行树。

设置为时none，不生成任何内存执行树。

设置为时allocs，内存执行树将给出当前分配的字节数和当前分配的块数。

设置为时full，内存执行树提供6种不同的度量：当前分配的字节和块数（与相同的值allocs），分配的字节和块总数，已释放的字节和块总数。

请注意，生成xtree的cpu和内存开销取决于工具。对于该值allocs，cpu的开销很小，因为生成此报告所需的信息在任何情况下都由该工具维护。对于massif和helgrind，指定full 意味着捕获每个自由操作的堆栈跟踪，而通常这些工具仅捕获分配堆栈跟踪。对于Memcheck，该值的cpu开销full很小，因为该值只能与--keep-stacktraces=alloc-and-free或 结合使用 --keep-stacktraces=alloc-then-free，它已经记录了每个空闲操作的堆栈跟踪。xtree中每个唯一堆栈跟踪的内存开销在5到10个字之间变化，如果专门针对xtree，则加上记录空闲操作的堆栈跟踪所需的内存。

--xtree-memory-file=<filename> [default: xtmemory.kcg.%p]

指定Valgrind应在指定文件中生成xtree内存报告。文件名中出现的任何%p或 %q序列都以与完全相同的方式扩展--log-file。有关 详细信息，请参见--log-file的描述。

如果文件名包含扩展名 .ms，那么生成的文件格式将是massif输出文件格式。如果文件名包含扩展名， .kcg 或者未提供或未识别任何扩展名，则生成的文件格式将为callgrind输出格式。

有关执行树格式的详细说明，请参见执行树。

2.6.5 ..罕见选项

--smc-check=<none|stack|all|all-non-file> [default: all-non-file for x86/amd64/s390x, stack for other archs]

此选项控制Valgrind对自修改代码的检测。如果不执行任何检查，则程序执行某些代码后，将其替换为新代码，然后执行新代码，Valgrind将继续执行对旧代码所做的翻译。这可能会导致错误的行为和/或崩溃。

对于“现代”体系结构（非x86，amd64或s390x的任何体系结构），默认值为stack。这是因为正确的程序必须在代码修改后必须采取显式操作来重新建立DI缓存一致性。Valgrind遵守并尊重此类行为，从而以零额外成本透明地处理了自修改代码。

对于x86，amd64和s390x，不需要程序将所需的DI相干同步通知硬件。因此，默认值是all-non-file，它涵盖了将代码生成到匿名（无文件支持）mmap'd区域的正常情况。

四个可用设置的含义如下。不检测（none），检测堆栈上的自我修改代码（GCC用于实现嵌套函数）（stack），在各处检测自我修改代码（all），并在除文件支持的映射之外的所有地方检测自我修改代码（）。all-non-file）。

与之赛跑all会使Valgrind明显减速。none由于大多数程序中很少动态生成代码，因此运行很少会加快速度。VALGRIND_DISCARD_TRANSLATIONS客户请求是该 请求的替代方案--smc-check=all ，--smc-check=all-non-file 它需要程序员付出更多的努力，但通过准确告知何时需要重新生成翻译，Valgrind可以更快地运行您的程序。

--smc-check=all-non-file提供更便宜但更受限制的--smc-check=all。它将检查添加到不是源自文件支持的内存映射的所有转换中。生成代码的典型应用程序（例如，Web浏览器中的JIT）将代码生成到匿名的映射区域中，而浏览器的“固定”代码始终位于文件支持的映射中。 --smc-check=all-non-file 利用这种观察，将检查的开销限制在可能是JIT生成的代码上。

--read-inline-info=<yes|no> [default: see below]

启用后，Valgrind将从DWARF3调试信息中读取有关内联函数调用的信息。这会减慢Valgrind的启动速度，并使它使用更多的内存（通常用于每个内联代码段，函数名称使用6个单词和空格），但会导致更具描述性的堆栈跟踪。当前，默认情况下仅针对Linux，Android和Solaris目标以及仅针对Memcheck，Massif，Helgrind和DRD工具启用此功能。这是一些带有以下内容的堆栈跟踪的示例 --read-inline-info=no：

==15380== Conditional jump or move depends on uninitialised value(s)
==15380==    at 0x80484EA: main (inlinfo.c:6)
==15380==
==15380== Conditional jump or move depends on uninitialised value(s)
==15380==    at 0x8048550: fun_noninline (inlinfo.c:6)
==15380==    by 0x804850E: main (inlinfo.c:34)
==15380==
==15380== Conditional jump or move depends on uninitialised value(s)
==15380==    at 0x8048520: main (inlinfo.c:6)

这是相同的错误 --read-inline-info=yes：

==15377== Conditional jump or move depends on uninitialised value(s)
==15377==    at 0x80484EA: fun_d (inlinfo.c:6)
==15377==    by 0x80484EA: fun_c (inlinfo.c:14)
==15377==    by 0x80484EA: fun_b (inlinfo.c:20)
==15377==    by 0x80484EA: fun_a (inlinfo.c:26)
==15377==    by 0x80484EA: main (inlinfo.c:33)
==15377==
==15377== Conditional jump or move depends on uninitialised value(s)
==15377==    at 0x8048550: fun_d (inlinfo.c:6)
==15377==    by 0x8048550: fun_noninline (inlinfo.c:41)
==15377==    by 0x804850E: main (inlinfo.c:34)
==15377==
==15377== Conditional jump or move depends on uninitialised value(s)
==15377==    at 0x8048520: fun_d (inlinfo.c:6)
==15377==    by 0x8048520: main (inlinfo.c:35)

--read-var-info=<yes|no> [default: no]

启用后，Valgrind将从DWARF3调试信息中读取有关变量类型和位置的信息。这会大大减慢Valgrind的启动速度，并大大占用更多内存，但是对于可以利用它的工具（Memcheck，Helgrind，DRD），它可以导致更精确的错误消息。例如，以下是Memcheck发出的一些标准错误：

==15363== Uninitialised byte(s) found during client check request
==15363==    at 0x80484A9: croak (varinfo1.c:28)
==15363==    by 0x8048544: main (varinfo1.c:55)
==15363==  Address 0x80497f7 is 7 bytes inside data symbol "global_i2"
==15363==
==15363== Uninitialised byte(s) found during client check request
==15363==    at 0x80484A9: croak (varinfo1.c:28)
==15363==    by 0x8048550: main (varinfo1.c:56)
==15363==  Address 0xbea0d0cc is on thread 1's stack
==15363==  in frame #1, created by main (varinfo1.c:45)

这是相同的错误 --read-var-info=yes：

==15370== Uninitialised byte(s) found during client check request
==15370==    at 0x80484A9: croak (varinfo1.c:28)
==15370==    by 0x8048544: main (varinfo1.c:55)
==15370==  Location 0x80497f7 is 0 bytes inside global_i2[7],
==15370==  a global variable declared at varinfo1.c:41
==15370==
==15370== Uninitialised byte(s) found during client check request
==15370==    at 0x80484A9: croak (varinfo1.c:28)
==15370==    by 0x8048550: main (varinfo1.c:56)
==15370==  Location 0xbeb4a0cc is 0 bytes inside local var "local"
==15370==  declared at varinfo1.c:46, in frame #1 of thread 1

--vgdb-poll=<number> [default: 5000]

作为其主循环的一部分，Valgrind调度程序将轮询以检查gdbserver是否必须处理某些活动（例如外部命令或来自gdb的某些输入）。该活动轮询将在运行给定数量的基本块（或略大于给定数量的基本块）之后进行。该轮询非常便宜，因此默认值设置得较低。如果在大多数情况下（大部分时间）所有线程都被阻塞，则vgdb无法使用ptrace系统调用来中断Valgrind，则可能会进一步减小该值。

--vgdb-shadow-registers=no|yes [default: no]

激活后，gdbserver会将Valgrind影子寄存器公开给GDB。这样，可以使用GDB检查或更改Valgrind影子寄存器的值。公开影子寄存器仅适用于GDB 7.1或更高版本。

--vgdb-prefix=<prefix> [default: /tmp/vgdb-pipe]

为了与gdb / vgdb通信，Valgrind gdbserver创建3个文件（2个命名为FIFO和mmap共享内存文件）。prefix选项控制用于创建这些文件的目录和前缀。

--run-libc-freeres=<yes|no> [default: yes]

仅当在Linux上运行Valgrind时，此选项才相关。

libc.so所有程序都使用的GNU C库（）可以分配内存供其自己使用。通常，在程序结束时它不会费心地释放该内存-这是没有意义的，因为Linux内核无论如何在进程退出时会回收所有进程资源，因此只会减慢速度。

glibc的作者意识到，这种行为会导致在退出时执行泄漏检查时，诸如Valgrind之类的泄漏检查程序错误地报告glibc中的泄漏。为了避免这种情况，他们提供了__libc_freeres 专门调用的例程，以使glibc释放其已分配的所有内存。因此，Memcheck尝试__libc_freeres在出口运行 。

不幸的是，在某些非常老的glibc版本中， __libc_freeres它的错误足以引起分段错误。这在Red Hat 7.1上尤其明显。因此提供此选项是为了禁止运行 __libc_freeres。如果您的程序似乎可以在Valgrind上正常运行，但是在退出时出现段错误，则您可能会发现此问题已 --run-libc-freeres=no解决，尽管这样做的代价是可能会错误地报告中的空间泄漏 libc.so。

--run-cxx-freeres=<yes|no> [default: yes]

仅当在Linux或Solaris C ++程序上运行Valgrind时，此选项才相关。

libstdc++.so由g ++编译的所有C ++程序都使用的GNU标准C ++库（）可以为自己使用分配内存。通常在程序结束时它不会费心地释放该内存，这是没有意义的，因为无论如何进程退出时内核都会回收所有进程资源，因此只会减慢速度。

gcc作者意识到，这种行为会导致在退出时执行泄漏检查的情况下，诸如Valgrind之类的泄漏检查器错误地报告libstdc ++中的泄漏。为了避免这种情况，他们提供了一个__gnu_cxx::__freeres 专门调用的例程，以使libstdc ++释放其已分配的所有内存。因此，Memcheck尝试__gnu_cxx::__freeres在出口运行 。

为了灵活性和不可预见的问题 __gnu_cxx::__freeres，--run-cxx-freeres=no存在选项 ，尽管以可能错误地报告中的空间泄漏为代价 libstdc++.so。

--sim-hints=hint1,hint2,...

向Valgrind传递其他提示，这些提示会以非标准或危险的方式稍微修改模拟的行为，可能有助于模拟奇怪的功能。默认情况下，不启用任何提示。请谨慎使用！当前已知的提示是：

--fair-sched=<no|yes|try> [default: no]

该--fair-sched选项控制Valgrind用于序列化线程执行的锁定机制。锁定机制控制线程的调度方式，并且不同的设置会在公平性和性能之间做出不同的权衡。有关Valgrind线程序列化方案及其对性能和线程调度的影响的更多详细信息，请参阅 调度和多线程性能。

--kernel-variant=variant1,variant2,...

处理此平台的默认内核的次要变体引起的系统调用和ioctl。例如，这对于在被黑内核或与支持非标准ioctl的内核模块上运行非常有用。请谨慎使用。如果您不了解此选项的功能，那么几乎可以肯定不需要它。当前已知的变体是：

--merge-recursive-frames=<number> [default: 0]

一些递归算法，例如平衡二叉树实现，会创建许多不同的堆栈跟踪，每个跟踪都包含调用周期。循环定义为两个相同的程序计数器值，它们之间被零个或多个其他程序计数器值分隔。然后，Valgrind可能会使用大量内存来存储所有这些堆栈跟踪。考虑到这样的堆栈跟踪包含重复的无趣的递归调用，而不是诸如启动递归调用的函数之类的更有趣的信息，这是对内存的不良使用。

该选项--merge-recursive-frames=<number> 指示Valgrind检测和合并最大为<number> 帧的递归调用周期。当检测到这样的循环时，Valgrind将循环作为唯一的程序计数器记录在堆栈跟踪中。

值0（默认值）不会导致递归调用合并。值为1将导致简单的递归算法（例如，阶乘实现）的堆栈跟踪崩溃。通常需要2的值来折叠由递归算法（例如二叉树，快速排序等）产生的堆栈跟踪。对于更复杂的递归算法，可能需要更高的值。

注意：递归调用是通过分析程序计数器值来检测的。通过查看函数名称无法检测到它们。

--num-transtab-sectors=<number> [default: 6 for Android platforms, 16 for all others]

Valgrind会以小片段（基本块）的形式翻译和检测程序的机器代码。翻译存储在翻译缓存中，翻译缓存分为多个部分（扇区）。如果缓存已满，则包含最旧翻译的扇区将被清空并重新使用。如果再次需要这些旧的翻译，Valgrind必须重新翻译并重新插入相应的机器代码，这很昂贵。如果程序的“执行指令”工作集很大，则增加扇区数可以通过减少所需的重新翻译次数来提高性能。部门按需分配。分配后，将永远无法释放一个扇区，并占用相当大的空间，具体取决于工具和工具的价值。--avg-transtab-entry-size （对于Memcheck，每个扇区大约40 MB）。使用该选项--stats=yes可获得有关扇区使用的内存以及扇区分配和回收的精确信息。

--avg-transtab-entry-size=<number> [default: 0, meaning use tool provided default]

翻译的基本块的平均大小。该平均大小用于确定一个扇区的大小。每个工具均提供要使用的默认值。如果此默认值太小，翻译扇区将变得太快充满。如果此默认值太大，则转换扇区内存的很大一部分将不使用。请注意，基本块转换的平均大小取决于工具，并且可能取决于工具选项。例如，memcheck选项--track-origins=yes 增加了基本块翻译的大小。使用--avg-transtab-entry-size调整扇区的大小，既可以增加内存或避免过多的重译。

--aspace-minaddr=<address> [default: depends on the platform]

为避免与某些系统库潜在冲突，Valgrind不会使用低于--aspace-minaddr值的地址空间，以防保留，以防库专门在该区域中请求内存。因此，Valgrind会根据平台猜测一些“悲观”值。在Linux上，默认情况下，Valgrind会避免使用前64MB，即使该完整区域中通常没有冲突也是如此。您可以使用该选项--aspace-minaddr使内存不足的应用程序从更多的较低内存中受益。另一方面，如果遇到冲突，增加aspace-minaddr值可能会解决。冲突通常会在地址空间的低范围内通过mmap故障表现出来。提供的address必须对齐页面，并且必须等于或大于0x1000（4KB）。要在您的平台上找到默认值，请执行 valgrind -d -d date 2>&1 | grep -i minaddr。已知小于0x10000（64KB）的值会在某些发行版上产生问题。

--valgrind-stacksize=<number> [default: 1MB]

对于每个线程，Valgrind需要其自己的“私有”堆栈。这些堆栈的默认大小在很大程度上已确定尺寸，因此在大多数情况下应该足够了。如果大小太小，Valgrind将会分段。在进行分段之前，Valgrind可能会在接近极限时发出警告。

--valgrind-stacksize如果产生这样的警告（不太可能），或者由于分割违规而导致Valgrind死亡， 请使用该选项。在拆分庞大的C ++符号时，已经看到了这种分段违规。

如果您的应用程序使用多个线程并需要大量内存，则可以使用option通过减小这些Valgrind堆栈的大小来获得一些内存--valgrind-stacksize。

--show-emwarns=<yes|no> [default: no]

启用后，Valgrind将在某些情况下发出有关其CPU仿真的警告。这些通常并不有趣。

--require-text-symbol=:sonamepatt:fnnamepatt

当将其soname匹配的共享库sonamepatt加载到进程中时，请检查其导出的所有文本符号。如果这些都不匹配fnnamepatt，则输出错误消息并放弃运行。这样可以确保除非给定的共享库包含特定的函数名称，否则运行不会继续。

两者sonamepatt和 fnnamepatt都可以使用常规?和*通配符编写 。例如：":*libc.so*:foo?bar"。您可以使用冒号以外的字符来分隔这两种模式。重要的是第一个字符和分隔符必须相同。例如，也可以编写以上示例"Q*libc.so*Qfoo?bar"。 --require-text-symbol允许使用多个标志，在这种情况下，将对照所有标志检查加载到进程中的共享对象。

这样做的目的是支持可靠使用标记的库。例如，假设我们有一个GCC版本，该版本 libgomp.so已标有注释以支持Helgrind。将错误的，未注释的错误加载libgomp.so到应用程序中太容易了，而且容易造成混乱 。这样的想法是：在标记的库中添加一个文本符号，例如annotated_for_helgrind_3_6，然后给出标志， --require-text-symbol=:*libgomp*so*:annotated_for_helgrind_3_6 以便在libgomp.so加载时Valgrind扫描其符号表，如果该符号不存在，则运行中止，而是而不是继续使用未标记的库。请注意，您应将整个标志放在引号中，以防止shell扩展* 和?通配符。

--soname-synonyms=syn1=pattern1,syn2=pattern2,...

加载共享库后，Valgrind会检查该库中必须替换或包装的函数。例如，Memcheck用自己的版本替换了一些字符串和内存函数（strchr，strlen，strcpy，memchr，memcpy，memmove等）。通常仅在soname与预定义的soname模式匹配的共享库中进行此类替换（例如， libc.so*在Linux上）。默认情况下，除了分配函数（malloc，free，calloc，memalign，realloc，operator new，operator delete等）外，不会对静态链接的二进制文件或替代库进行任何替换。默认情况下，此类分配函数在任何共享库或可执行文件中的共享库（如果它们被导出为全局符号）。这意味着，如果找到替换分配库（例如tcmalloc），则默认情况下也会拦截其功能。在某些情况下，替换允许 --soname-synonyms指定一个附加的同义词模式，从而为替换提供了灵活性。或防止拦截所有公共分配符号。

当前，仅使用同义词与malloc相关的功能才允许这种灵活性somalloc。此同义词可用于所有与malloc相关功能进行标准替换的工具（例如memcheck，helgrind，drd，massif，dhat，exp-sgcheck）。

--progress-interval=<number> [default: 0, meaning 'disabled']

这是对Valgrind调试输出的增强。最终用户不太可能感兴趣。

当number设置为非零值时，Valgrind将每秒钟打印一行一行的进度摘要number。有效的设置number介于0和3600之间（含0和3600）。这是一些number 设置为10的示例输出：

PROGRESS: U 110s, W 113s, 97.3% CPU, EvC 414.79M, TIn 616.7k, TOut 0.5k, #thr 67
PROGRESS: U 120s, W 124s, 96.8% CPU, EvC 505.27M, TIn 636.6k, TOut 3.0k, #thr 64
PROGRESS: U 130s, W 134s, 97.0% CPU, EvC 574.90M, TIn 657.5k, TOut 3.0k, #thr 63

每行显示：

从这些进展中，可以观察到：

2.6.6. 调试选项

2.6.7. 设置默认选项

1. 文件 ~/.valgrindrc

2. 环境变量 $VALGRIND_OPTS

3. 文件 ./.valgrindrc

--memcheck:leak-check=yes

2.7.1.``计划和多线程性能