運(yùn)行Valgrind工具toolname，例如memcheck，cachegrind，callgrind，helgrind，drd，massif，lackey，none，exp-sgcheck，exp-bbv，exp-dhat等

顯示所有選項(xiàng)的幫助，包括核心和所選工具。如果該選項(xiàng)重復(fù)，則相當(dāng)于給予?--help-debug。

--help與之一樣，但也列出了通常僅用于Valgrind開(kāi)發(fā)人員的調(diào)試選項(xiàng)。

顯示Valgrind內(nèi)核的版本號(hào)。工具可以有自己的版本號(hào)。有一個(gè)方案來(lái)確保只有核心版本是已知的工具才能執(zhí)行的工具。這樣做是為了盡量減少由于工具與核心版本不兼容而產(chǎn)生的奇怪問(wèn)題的機(jī)會(huì)。

靜默運(yùn)行，只打印錯(cuò)誤消息。如果您正在進(jìn)行回歸測(cè)試或有其他自動(dòng)化測(cè)試機(jī)器，那么有用。

更冗長(zhǎng)?提供有關(guān)程序各個(gè)方面的更多信息，例如：加載的共享對(duì)象，使用的禁用，檢測(cè)和執(zhí)行引擎的進(jìn)度以及有關(guān)異常行為的警告。重復(fù)該選項(xiàng)會(huì)增加詳細(xì)程度。

啟用后，Valgrind將跟蹤通過(guò)exec系統(tǒng)調(diào)用發(fā)起的子進(jìn)程。這對(duì)于多進(jìn)程程序是必需的。

請(qǐng)注意，Valgrind確實(shí)會(huì)追蹤到一個(gè)fork（的孩子）?，因?yàn)?fork這樣一個(gè)進(jìn)程的相同拷貝就很難，所以這個(gè)選項(xiàng)可能被命名得很糟。然而，大多數(shù)fork電話的孩子?立即打電話exec?。

此選項(xiàng)僅在指定時(shí)--trace-children=yes才有效果?。它允許一些孩子被跳過(guò)。該選項(xiàng)為Valgrind不應(yīng)該跟蹤的可執(zhí)行文件的名稱使用逗號(hào)分隔的模式列表。這些模式可以包括元字符??和*，它們具有通常的意義。

這可以用于從Valgrind上運(yùn)行的進(jìn)程樹(shù)中修剪不感興趣的分支。但是，使用它時(shí)應(yīng)該小心。當(dāng)Valgrind跳過(guò)跟蹤到可執(zhí)行文件時(shí)，它不會(huì)跳過(guò)跟蹤該可執(zhí)行文件，它也跳過(guò)跟蹤任何可執(zhí)行文件的子進(jìn)程。換句話說(shuō)，該標(biāo)志不僅僅是引起跟蹤停止在指定的可執(zhí)行文件 - 它跳過(guò)跟蹤任何一個(gè)指定的可執(zhí)行文件的整個(gè)進(jìn)程子樹(shù)。

這是一樣的?--trace-children-skip，有一個(gè)區(qū)別：關(guān)于是否追蹤到子進(jìn)程的決定是通過(guò)檢查子進(jìn)程的參數(shù)而不是其可執(zhí)行文件的名稱來(lái)進(jìn)行的。

啟用后，Valgrind不會(huì)顯示任何來(lái)自fork調(diào)用的子進(jìn)程的調(diào)試或記錄輸出。這可以使輸出在處理創(chuàng)建子進(jìn)程時(shí)更不容易混淆（盡管更具誤導(dǎo)性）。它特別有用--trace-children=。如果要求XML輸出（--xml=yes），則強(qiáng)烈建議使用此選項(xiàng)，否則來(lái)自子級(jí)和父級(jí)的XML可能會(huì)混淆，這通常會(huì)使其無(wú)用。

當(dāng)Valgrind的將提供“gdbserver的”功能?--vgdb=yes或--vgdb=full指定的。這允許外部GNU GDB調(diào)試器在Valgrind上運(yùn)行時(shí)控制和調(diào)試程序。?--vgdb=full引起顯著的性能開(kāi)銷，但提供更精確的斷點(diǎn)和觀察點(diǎn)。有關(guān)詳細(xì)說(shuō)明，請(qǐng)參閱使用Valgrind的gdbserver和GDB調(diào)試程序。

如果嵌入式gdbserver已啟用但目前沒(méi)有使用gdb，則vgdb?命令行實(shí)用程序可以從shell向Valgrind發(fā)送“監(jiān)視器命令”。Valgrind內(nèi)核提供一組?Valgrind監(jiān)視器命令。工具可以選擇提供特定于工具的監(jiān)視器命令，這些命令在工具特定的章節(jié)中有所記錄。

當(dāng)Valgrind gdbserver啟用--vgdb=yes或時(shí)，使用此選項(xiàng)?--vgdb=full。報(bào)告錯(cuò)誤的工具將number在凍結(jié)程序并等待您與GDB連接之前等待“?”錯(cuò)誤報(bào)告。因此，值為零將導(dǎo)致在執(zhí)行程序之前啟動(dòng)gdbserver。這通常用于在執(zhí)行前插入GDB斷點(diǎn)，并且還可以與不報(bào)告錯(cuò)誤的工具（如Massif）一起使用。

當(dāng)Valgrind gdbserver啟用--vgdb=yes或時(shí)，使用此選項(xiàng)?--vgdb=full。--vgdb-error報(bào)告之后，將為每個(gè)錯(cuò)誤調(diào)用Valgrind gdbserver?。您還可以詢問(wèn)為其他事件調(diào)用Valgrind gdbserver，以下列方式之一指定：

• 一個(gè)或多個(gè)逗號(hào)分隔的列表?startup exit valgrindabexit。

  值startup?exit?valgrindabexit分別表示在程序執(zhí)行之前，在程序的最后一個(gè)指令之后，在Valgrind異常退出（例如內(nèi)部錯(cuò)誤，內(nèi)存不足，...）中調(diào)用gdbserver。

  注意：startup并且?--vgdb-error=0將會(huì)在程序執(zhí)行之前調(diào)用Valgrind gdbserver。此外?--vgdb-error=0，還將導(dǎo)致您的程序停止所有后續(xù)錯(cuò)誤。

• all指定完整集。相當(dāng)于?--vgdb-stop-at=startup,exit,valgrindabexit。

• none?為空集。

啟用后，Valgrind將通過(guò)gdbserver monitor命令在出口或請(qǐng)求時(shí)打印出打開(kāi)的文件描述符列表v.info open_fds。與每個(gè)文件描述符一起打印文件打開(kāi)位置的堆棧回溯以及與文件描述符相關(guān)的任何細(xì)節(jié)，如文件名或套接字詳細(xì)信息。

啟用后，每個(gè)消息之前都會(huì)顯示自啟動(dòng)以來(lái)的已經(jīng)逝去的時(shí)鐘，表示為天，小時(shí)，分鐘，秒和毫秒。

指定Valgrind應(yīng)將其所有消息發(fā)送到指定的文件描述符。默認(rèn)值2是標(biāo)準(zhǔn)錯(cuò)誤通道（stderr）。請(qǐng)注意，這可能會(huì)干擾客戶端自己使用stderr，因?yàn)閂algrind的輸出將與客戶端發(fā)送給stderr的任何輸出交錯(cuò)。

指定Valgrind應(yīng)將其所有郵件發(fā)送到指定的文件。如果文件名為空，則會(huì)導(dǎo)致中止。有三種特殊的格式說(shuō)明符可以在文件名中使用。

%p被當(dāng)前進(jìn)程ID替換。這對(duì)于調(diào)用多個(gè)進(jìn)程的程序非常有用。警告：如果您使用--trace-children=yes并且您的程序調(diào)用多個(gè)進(jìn)程或您的程序fork而不調(diào)用exec，并且您不使用此說(shuō)明符（或%q下面的說(shuō)明符），則所有這些進(jìn)程的Valgrind輸出將進(jìn)入一個(gè)文件，可能會(huì)混亂并且可能不完整。

%q{FOO}被替換為環(huán)境變量的內(nèi)容FOO。如果?{FOO}部件畸形，會(huì)導(dǎo)致中止。此說(shuō)明符很少需要，但在某些情況下（例如運(yùn)行MPI程序時(shí)）非常有用。這個(gè)想法是指定一個(gè)變量，該變量將為作業(yè)中的每個(gè)進(jìn)程設(shè)置不同，例如BPROC_RANK或MPI設(shè)置中適用的任何內(nèi)容。如果未設(shè)置命名環(huán)境變量，則會(huì)導(dǎo)致中止。請(qǐng)注意，在某些shell中，?角色{和}角色可能需要使用反斜杠進(jìn)行轉(zhuǎn)義。

%%被替換%。

如果%其后的任何其他字符，則導(dǎo)致中止。

如果文件名指定相對(duì)文件名，則將其放入程序的初始工作目錄中：當(dāng)程序在fork之后或exec之后執(zhí)行時(shí)，這是當(dāng)前目錄。如果它指定絕對(duì)文件名（即以'/'開(kāi)始），那么它將放在那里。

指定Valgrind應(yīng)將其所有消息發(fā)送到指定IP地址的指定端口。可以省略端口，在這種情況下使用端口1500。如果無(wú)法連接到指定的套接字，則Valgrind將返回寫入標(biāo)準(zhǔn)錯(cuò)誤（stderr）的輸出。此選項(xiàng)旨在與valgrind-listener程序一起使用?。有關(guān)詳細(xì)信息，請(qǐng)參閱?手冊(cè)中的注釋。

啟用時(shí)，輸出的重要部分（例如工具錯(cuò)誤消息）將采用XML格式而不是純文本格式。此外，XML輸出將被發(fā)送到與純文本輸出不同的輸出通道。因此，還必須使用的一個(gè)?--xml-fd，--xml-file或?--xml-socket到指定的XML將被發(fā)送。

不太重要的消息將仍然以純文本被打印，但是，因?yàn)閄ML輸出和明文輸出被發(fā)送到不同的輸出信道（純文本輸出的目的地仍然由控制--log-fd，--log-file?和--log-socket）這不應(yīng)引起問(wèn)題。

此選項(xiàng)旨在使消費(fèi)Valgrind輸出的工具（如GUI前端）變得更簡(jiǎn)單。目前這個(gè)選項(xiàng)適用于Memcheck，Helgrind，DRD和SGcheck。輸出格式在docs/internals/xml-output-protocol4.txt?Valgrind 3.5.0或更高版本的源代碼樹(shù)中的文件?中指定。

GUI請(qǐng)求XML輸出時(shí)，推薦的選項(xiàng)是：--xml=yes啟用XML輸出，?--xml-file將XML輸出發(fā)送到（大概是GUI選擇的）文件，--log-file將純文本輸出發(fā)送到第二個(gè)GUI選擇的文件，?--child-silent-after-fork=yes，并將?-q純文本輸出限制為由Valgrind本身創(chuàng)建的關(guān)鍵錯(cuò)誤消息。例如，無(wú)法讀取指定的抑制文件將被視為關(guān)鍵錯(cuò)誤消息。這樣，為了成功運(yùn)行文本輸出文件將為空。但是如果它不是空的，那么它將包含GUI用戶應(yīng)該注意的重要信息。

指定Valgrind應(yīng)將其XML輸出發(fā)送到指定的文件描述符。它必須與之配合使用?--xml=yes。

指定Valgrind應(yīng)將其XML輸出發(fā)送到指定的文件。它必須與之配合使用?--xml=yes。出現(xiàn)在文件名中的任何%p或者?%q序列以與它們完全相同的方式進(jìn)行擴(kuò)展--log-file。有關(guān)--log-file詳細(xì)信息，請(qǐng)參閱說(shuō)明。

指定Valgrind應(yīng)將指定端口的XML輸出發(fā)送到指定的IP地址。它必須與之配合使用--xml=yes。參數(shù)的形式與使用的形式相同--log-socket。有關(guān)--log-socket?詳細(xì)信息，請(qǐng)參閱說(shuō)明。

在XML輸出的開(kāi)始處嵌入一個(gè)額外的用戶注釋字符串。僅在--xml=yes指定時(shí)才能工作;?否則忽略。

啟用/禁用C ++名稱的自動(dòng)解碼（解碼）。默認(rèn)啟用。啟用后，Valgrind將嘗試將編碼的C ++名稱轉(zhuǎn)換為接近原始文件的東西。demangler處理由g ++版本2.X，3.X和4.X驅(qū)動(dòng)的符號(hào)。

關(guān)于解密的一個(gè)重要事實(shí)是在壓制文件中提到的函數(shù)名稱應(yīng)該處于它們的格式。在搜索適用的抑制方面，Valgrind不會(huì)使功能名稱發(fā)生拆分，因?yàn)榉駝t會(huì)使壓縮文件內(nèi)容取決于Valgrind的分離機(jī)器的狀態(tài)，并且還會(huì)減緩抑制匹配。

指定標(biāo)識(shí)程序位置的堆棧跟蹤中顯示的最大條目數(shù)。請(qǐng)注意，僅使用前四個(gè)功能位置（當(dāng)前功能中的位置，以及其三個(gè)直接調(diào)用者的位置）常見(jiàn)錯(cuò)誤。所以這并不影響所報(bào)錯(cuò)誤的總數(shù)。

最大值為500.請(qǐng)注意，較高的設(shè)置將使Valgrind運(yùn)行速度更慢，并占用更多內(nèi)存，但在使用深嵌套的調(diào)用鏈的程序時(shí)可能會(huì)很有用。

堆棧掃描支持僅在ARM目標(biāo)上可用。

這些標(biāo)志通過(guò)堆棧掃描啟用和控制堆棧展開(kāi)。當(dāng)正常堆棧展開(kāi)機(jī)制 - 使用Dwarf CFI記錄和幀指針跟隨失敗時(shí)，堆棧掃描可能能夠恢復(fù)堆棧跟蹤。

請(qǐng)注意，堆棧掃描是一種不精確的啟發(fā)式機(jī)制，可能會(huì)產(chǎn)生非常誤導(dǎo)的結(jié)果，或者根本沒(méi)有。它只能在緊急情況下使用，正常展開(kāi)失敗，重要的是仍然有堆棧跟蹤。

堆棧掃描是一種簡(jiǎn)單的技術(shù)：展開(kāi)器從堆棧中讀取單詞，并嘗試猜測(cè)哪些可能是返回地址，通過(guò)檢查它們是否指向ARM或Thumb調(diào)用指令。如果是這樣，該詞被添加到回溯。

當(dāng)函數(shù)調(diào)用返回時(shí)，會(huì)發(fā)生主要的危險(xiǎn)，其返回地址被暴露，并且調(diào)用一個(gè)新的函數(shù)，但新函數(shù)不會(huì)覆蓋舊的地址。這樣做的結(jié)果是回溯可能包含已經(jīng)返回的函數(shù)的條目，因此非常混亂。

此實(shí)現(xiàn)的第二個(gè)限制是它將僅掃描包含起始堆棧指針的頁(yè)面（通常為4KB）。如果堆棧幀較大，則這可能導(dǎo)致軌跡中僅存在少量（甚至不甚甚）。此外，如果您不幸運(yùn)，并且在其包含頁(yè)面的末尾附近有一個(gè)初始堆棧指針，掃描可能會(huì)錯(cuò)過(guò)所有有趣的幀。

默認(rèn)情況下，堆棧掃描被禁用。正常的使用情況是要求堆棧跟蹤否則會(huì)很短。所以，啟用它，使用--unw-stack-scan-thresh=number。這要求Valgrind嘗試使用堆棧掃描來(lái)“擴(kuò)展”包含少于number幀的堆棧跟蹤。

如果堆棧掃描發(fā)生，它將只生成最多指定的幀數(shù)--unw-stack-scan-frames。通常，堆棧掃描會(huì)生成這么多垃圾條目，默認(rèn)情況下該值設(shè)置為低值（5）。在任何情況下，堆棧跟蹤大于--num-callers創(chuàng)建指定的值。

啟用后，Valgrind停止報(bào)告錯(cuò)誤，總共有10,000,000個(gè)，或者1,000個(gè)不同的。這是為了阻止錯(cuò)誤跟蹤機(jī)制在具有許多錯(cuò)誤的程序中成為巨大的性能開(kāi)銷。

如果Valgrind在運(yùn)行中報(bào)告任何錯(cuò)誤，則指定返回的替代退出代碼。當(dāng)設(shè)置為默認(rèn)值（零）時(shí)，Valgrind的返回值將始終是正在仿真的進(jìn)程的返回值。當(dāng)設(shè)置為非零值時(shí)，將返回該值，如果Valgrind檢測(cè)到任何錯(cuò)誤。這對(duì)于使用Valgrind作為自動(dòng)化測(cè)試套件的一部分非常有用，因?yàn)橥ㄟ^(guò)檢查返回碼，可以輕松檢測(cè)Valgrind報(bào)告錯(cuò)誤的測(cè)試用例。

當(dāng)錯(cuò)誤輸出為純文本（即XML未使用）時(shí)，?--error-markers指示在每個(gè)錯(cuò)誤之前（之后）輸出包含begin（end）字符串的行。

這樣的標(biāo)記線便于搜索包含與程序輸出混合的valgrind錯(cuò)誤的輸出文件中的錯(cuò)誤和/或提取錯(cuò)誤。

請(qǐng)注意，空標(biāo)記被接受。因此，只能使用開(kāi)始（或結(jié)束）標(biāo)記。

啟用/禁用打印非法指令診斷。默認(rèn)情況下啟用，但默認(rèn)為禁用?--quiet。通過(guò)給出此選項(xiàng)，總是可以明確地覆蓋默認(rèn)值。

啟用該功能后，在程序發(fā)出SIGILL信號(hào)之前，每當(dāng)遇到Valgrind無(wú)法解碼或轉(zhuǎn)換的指令時(shí)，都會(huì)打印一條警告消息以及一些診斷信息。通常，非法指令表示程序中的錯(cuò)誤或缺少對(duì)Valgrind特定指令的支持。但有些程序會(huì)故意嘗試執(zhí)行可能丟失的指令，并捕獲SIGILL信號(hào)以檢測(cè)處理器功能。使用此標(biāo)志可以避免在這種情況下您會(huì)得到的診斷輸出。

默認(rèn)情況下，錯(cuò)誤的堆棧跟蹤不會(huì)顯示下面的任何函數(shù)，main因?yàn)榇蠖鄶?shù)時(shí)候它不感興趣C庫(kù)東西和/或gobbledygook。或者，如果main堆棧跟蹤中不存在堆棧跟蹤，堆棧跟蹤將不會(huì)顯示main類似函數(shù)（如glibc）的?任何函數(shù)__libc_start_main。此外，如果?main跟蹤中存在類似函數(shù)，則它們被歸一化為(below main)使得輸出更確定。

如果啟用此選項(xiàng)，將顯示所有堆棧跟蹤條目，并且main類似的函數(shù)將不會(huì)被歸一化。

默認(rèn)情況下，Valgrind僅顯示堆棧跟蹤中的文件名，但不顯示源文件的完整路徑。當(dāng)在大型項(xiàng)目中使用Valgrind，其中源位于多個(gè)不同的目錄中時(shí)，這可能是不方便的。?--fullpath-after為這個(gè)問(wèn)題提供了靈活的解決方案。當(dāng)此選項(xiàng)存在時(shí)，將顯示每個(gè)源文件的路徑，其中包含以下所有重要的注意事項(xiàng)：如果string在路徑中找到，則將string省略直到和包含的路徑，否則路徑未修改。注意，string不需要作為路徑的前綴。

例如，考慮一個(gè)名為的文件?/home/janedoe/blah/src/foo/bar/xyzzy.c。指定--fullpath-after=/home/janedoe/blah/src/?將導(dǎo)致Valgrind顯示名稱foo/bar/xyzzy.c。

因?yàn)樽址恍枰鳛榍熬Y，所以?--fullpath-after=src/會(huì)產(chǎn)生相同的輸出。當(dāng)路徑包含任意機(jī)器生成的字符時(shí)，這很有用。例如，/my/build/dir/C32A1B47/blah/src/foo/xyzzy?可以修剪路徑?以foo/xyzzy?使用?--fullpath-after=/blah/src/。

如果您只想看到完整的路徑，只需指定一個(gè)空字符串：--fullpath-after=。這不是一個(gè)特殊情況，只是上述規(guī)則的邏輯后果。

最后，你可以--fullpath-after?多次使用。任何外觀都會(huì)導(dǎo)致Valgrind切換到生成完整路徑并應(yīng)用上述過(guò)濾規(guī)則。每個(gè)生成的路徑按照--fullpath-after指定的順序與所有指定的字符串進(jìn)行比較。要匹配的第一個(gè)字符串將導(dǎo)致路徑被截?cái)?#xff0c;如上所述。如果不匹配，則顯示完整路徑。當(dāng)源從多個(gè)不相關(guān)的目錄中抽取時(shí)，這有助于切除前綴。

默認(rèn)情況下，Valgrind在幾個(gè)眾所周知的路徑中搜索調(diào)試對(duì)象，例如/usr/lib/debug/。

但是，您可能希望將調(diào)試對(duì)象放置在任意位置，例如在具有有限本地存儲(chǔ)空間的移動(dòng)設(shè)備上運(yùn)行Valgrind時(shí)的外部存儲(chǔ)。另一個(gè)例子可能是您沒(méi)有在運(yùn)行Valgrind的系統(tǒng)上安裝調(diào)試對(duì)象包的權(quán)限的情況。

在這些情況下，您可以提供絕對(duì)路徑作為Valgrind通過(guò)指定搜索調(diào)試對(duì)象的額外最終位置?--extra-debuginfo-path=/path/to/debug/objects。給定的路徑將被添加到搜索對(duì)象的絕對(duì)路徑名稱。例如，如果Valgrind正在尋找/w/x/y/zz.so?和--extra-debuginfo-path=/a/b/c指定的debuginfo，那么它將在此處查找一個(gè)調(diào)試對(duì)象?/a/b/c/w/x/y/zz.so。

該標(biāo)志只能指定一次。如果指定多次，則只會(huì)保留最后一個(gè)實(shí)例。

這是在3.9.0版本中引入的一個(gè)新的，實(shí)驗(yàn)性的功能。

在某些情況下，從存儲(chǔ)在不同機(jī)器上的對(duì)象讀取debuginfo可能很方便。使用此標(biāo)志，Valgrind將在本地文件系統(tǒng)中找不到debuginfo對(duì)象時(shí)查詢運(yùn)行在ipaddr偵聽(tīng)端口上的debuginfo服務(wù)器port。

debuginfo服務(wù)器必須接受端口上的TCP連接port。debuginfo服務(wù)器包含在源文件中auxprogs/valgrind-di-server.c。它將僅從它啟動(dòng)的目錄中提供。?port如果未指定，默認(rèn)為客戶端和服務(wù)器的1500。

如果Valgrind?/w/x/y/zz.so通過(guò)使用debuginfo服務(wù)器查找debuginfo，它將剝離路徑名組件，并僅zz.so在服務(wù)器上請(qǐng)求。反過(guò)來(lái)，它將僅在其當(dāng)前工作目錄中查找匹配的debuginfo對(duì)象。

根據(jù)Valgrind的要求，debuginfo數(shù)據(jù)以小片段（8 KB）傳輸。使用LZO壓縮每個(gè)塊以減少傳輸時(shí)間。通過(guò)單階段802.11g（WiFi）網(wǎng)絡(luò)鏈路實(shí)現(xiàn)了最佳性能。

請(qǐng)注意，即使使用debuginfo服務(wù)器，也會(huì)執(zhí)行使用GNU debuglink CRC方案來(lái)匹配主要和調(diào)試對(duì)象的檢查。要禁用此類檢查，您還需要指定?--allow-mismatched-debuginfo=yes。

默認(rèn)情況下，Valgrind構(gòu)建系統(tǒng)將為valgrind-di-server目標(biāo)平臺(tái)構(gòu)建，這幾乎肯定不是您想要的。到目前為止，我們一直無(wú)法找到如何獲取automake / autoconf來(lái)構(gòu)建它的構(gòu)建平臺(tái)。如果要使用它，則必須使用頂部顯示的命令手動(dòng)重新編譯它auxprogs/valgrind-di-server.c。

當(dāng)從單獨(dú)的debuginfo對(duì)象讀取debuginfo時(shí)，Valgrind將默認(rèn)使用GNU debuglink機(jī)制檢查main和debuginfo對(duì)象是否匹配。這樣保證它不會(huì)從過(guò)期的debuginfo對(duì)象中讀取debuginfo，并且還可以確保Valgrind不會(huì)因?yàn)椴黄ヅ涠罎ⅰ?/p>

此檢查可以使用?--allow-mismatched-debuginfo=yes。當(dāng)debuginfo和主對(duì)象沒(méi)有以正確的方式拆分時(shí)，這可能很有用。盡管如此，使用它時(shí)要小心：它禁用所有一致性檢查，并且當(dāng)主要和debuginfo對(duì)象不匹配時(shí)，Valgrind被觀察到崩潰。

指定一個(gè)額外的文件，從中讀取要抑制的錯(cuò)誤的描述。您可以使用多達(dá)100個(gè)額外的壓縮文件。

設(shè)置后yes，Valgrind將在每次顯示錯(cuò)誤后暫停，并打印行：

????----?Print?suppression???---?[Return/N/n/Y/y/C/c]?----

按Ret或，N Ret或?n Ret導(dǎo)致Valgrind繼續(xù)執(zhí)行而不打印此錯(cuò)誤的抑制。

按下Y Ret或?y Ret導(dǎo)致Valgrind寫入此錯(cuò)誤的抑制。如果您不想再聽(tīng)到有關(guān)該錯(cuò)誤的信息，可以將其剪切并粘貼到抑制文件中。

設(shè)置時(shí)all，Valgrind將會(huì)針對(duì)每個(gè)報(bào)告的錯(cuò)誤打印一個(gè)抑制，而不會(huì)查詢用戶。

此選項(xiàng)對(duì)于C ++程序特別有用，因?yàn)樗鶕?jù)需要打印出具有破壞名稱的抑制。

請(qǐng)注意，打印的壓印盡可能具體。您可能希望通過(guò)添加通配符到函數(shù)名稱以及使用幀級(jí)別的通配符來(lái)尋找類似的通配符。通配設(shè)備功能強(qiáng)大而靈活，并且經(jīng)過(guò)仔細(xì)的編輯，您可能只需少量的壓制即可抑制整個(gè)系列的相關(guān)錯(cuò)誤。

有時(shí)兩個(gè)不同的錯(cuò)誤被同樣的抑制所壓制，在這種情況下，Valgrind將會(huì)多次輸出抑制，但您只需要在壓縮文件中有一個(gè)副本（但是不止一個(gè)則不會(huì)導(dǎo)致問(wèn)題）。此外，抑制名稱為?<insert a suppression name here>：該名稱并不重要，它只用于-v打印所有使用的抑制記錄的選項(xiàng)。

當(dāng)使用?--gen-suppressions=yes時(shí)，Valgrind將停止，以便在發(fā)生每個(gè)錯(cuò)誤時(shí)讀取您的鍵盤輸入。默認(rèn)情況下，它從標(biāo)準(zhǔn)輸入（stdin）讀取，這對(duì)于關(guān)閉stdin的程序是有問(wèn)題的。此選項(xiàng)允許您指定從中讀取輸入的備用文件描述符。

此選項(xiàng)僅在Mac OS X上運(yùn)行Valgrind時(shí)才有用。

Mac OS X使用延遲調(diào)試信息（debuginfo）鏈接方案。當(dāng)包含debuginfo的對(duì)象文件鏈接到一個(gè).dylib或可執(zhí)行文件中時(shí)，debuginfo不會(huì)被復(fù)制到最終文件中。相反，必須通過(guò)在可執(zhí)行文件上運(yùn)行dsymutil系統(tǒng)提供的實(shí)用程序來(lái)手動(dòng)鏈接debuginfo?.dylib。生成的組合debuginfo放在可執(zhí)行文件旁邊的目錄中，或者.dylib擴(kuò)展名.dSYM。

使用--dsymutil=no，Valgrind將檢測(cè)?.dSYM目錄丟失或存在的情況，但不符合關(guān)聯(lián)的可執(zhí)行文件，或者.dylib很可能是因?yàn)樗堰^(guò)期。在這種情況下，Valgrind會(huì)打印一個(gè)警告消息，但不采取進(jìn)一步行動(dòng)。

隨著--dsymutil=yes，Valgrind的意志，在這樣的情況下，自動(dòng)運(yùn)行dsymutil必要使debuginfo軟最新的。對(duì)于所有實(shí)際的目的，如果您始終使用--dsymutil=yes，則絕對(duì)不需要dsymutil手動(dòng)運(yùn)行或作為應(yīng)用程序構(gòu)建系統(tǒng)的一部分運(yùn)行，因?yàn)閂algrind將根據(jù)需要運(yùn)行它。

Valgrind的不會(huì)嘗試運(yùn)行dsymutil在任何可執(zhí)行文件或庫(kù)?/usr/，?/bin/，?/sbin/，?/opt/，?/sw/，?/System/，?/Library/或?/Applications/?因?yàn)閐symutil總是會(huì)在這種情況下失敗。它失敗了，因?yàn)檫@種預(yù)安裝的系統(tǒng)組件的debuginfo在任何地方都不可用，也因?yàn)樗枰@些目錄中的寫入權(quán)限。

使用--dsymutil=yes時(shí)要小心，因?yàn)樗鼤?huì)導(dǎo)致預(yù)先存在的.dSYM?目錄被靜默刪除并重新創(chuàng)建。還要注意的?dsymutil是相當(dāng)慢，有的時(shí)候太過(guò)分了。

堆棧幀的最大大小。如果堆棧指針移動(dòng)超過(guò)此值，則Valgrind將假定程序正在切換到另一個(gè)堆棧。

如果您的程序具有大量堆棧分配的數(shù)組，則可能需要使用此選項(xiàng)。Valgrind跟蹤程序的堆棧指針。如果它改變超過(guò)閾值，Valgrind假設(shè)您的程序正在切換到不同的堆棧，Memcheck的行為與堆棧指針變化小于閾值的行為不同。通常這個(gè)啟發(fā)式工作原理很好。但是，如果您的程序在堆棧中分配大型結(jié)構(gòu)，則該啟發(fā)式將被愚弄，并且Memcheck將會(huì)報(bào)告大量的無(wú)效堆棧訪問(wèn)。此選項(xiàng)允許您將閾值更改為不同的值。

如果Valgrind的調(diào)試輸出指示您這樣做，您應(yīng)該僅考慮使用此選項(xiàng)。在這種情況下，它會(huì)告訴您應(yīng)該指定的新閾值。

通常，在堆棧上分配大型結(jié)構(gòu)是一個(gè)壞主意，因?yàn)槟梢暂p松地耗盡堆棧空間，特別是在內(nèi)存有限的系統(tǒng)上，或者希望支持大量線程，每個(gè)都有一個(gè)小堆棧，并且還因?yàn)殄e(cuò)誤由Memcheck執(zhí)行的檢查對(duì)堆分配數(shù)據(jù)比對(duì)堆棧分配的數(shù)據(jù)更有效。如果您必須使用此選項(xiàng)，您可能希望考慮將代碼重寫為在堆上分配而不是堆棧。

指定主線程堆棧的大小。

為了簡(jiǎn)化內(nèi)存管理，Valgrind在啟動(dòng)時(shí)保留主線程堆棧的所有空間。這意味著它需要在啟動(dòng)時(shí)知道所需的堆棧大小。

默認(rèn)情況下，Valgrind使用當(dāng)前的“ulimit”值作為堆棧大小，或16 MB，以較低者為準(zhǔn)。在許多情況下，這將提供8到16 MB的堆棧大小，對(duì)于大多數(shù)應(yīng)用程序幾乎不會(huì)溢出。

如果您需要更大的總堆棧大小，請(qǐng)使用--main-stacksize它來(lái)指定它。只需將其設(shè)置為您所需的高度，因?yàn)楸Ａ舯饶枰母嗫臻g（即，比您需要的數(shù)百兆字節(jié)）約束了Valgrind的內(nèi)存分配器，并可能減少Valgrind可以使用的內(nèi)存總量。這對(duì)32位機(jī)器來(lái)說(shuō)真的很重要。

在Linux上，您可以要求一個(gè)大小為2GB的堆棧。如果無(wú)法分配堆棧，Valgrind將會(huì)停止診斷消息。

--main-stacksize只影響程序初始線程的堆棧大小。它對(duì)線程棧的大小沒(méi)有任何影響，因?yàn)閂algrind不會(huì)分配它們。

您可能需要同時(shí)使用--main-stacksize?和--max-stackframe在一起。重要的是要理解，--main-stacksize設(shè)置最大堆棧總數(shù)，同時(shí)--max-stackframe指定任何一個(gè)堆棧幀的最大大小。您將必須--main-stacksize為自己找出價(jià)值（通常，如果您的應(yīng)用程序發(fā)生故障）。但是--max-stackframe，如果需要，Valgrind會(huì)告訴你需要的尺寸。

如在描述中進(jìn)一步討論的--max-stackframe，對(duì)于大堆棧的要求是潛在可移植性問(wèn)題的跡象。最好建議將所有大數(shù)據(jù)放在堆分配的內(nèi)存中。

默認(rèn)情況下，Valgrind最多可處理500個(gè)線程。偶爾，這個(gè)數(shù)字太小了。使用此選項(xiàng)提供不同的限制。例如?--max-threads=3000。

默認(rèn)情況下Valgrind的的malloc，?realloc等等，返回塊，其起始地址為8字節(jié)對(duì)齊或16字節(jié)對(duì)齊（數(shù)值取決于平臺(tái)和相匹配的平臺(tái)默認(rèn)）。此選項(xiàng)允許您指定不同的對(duì)齊方式。提供的值必須大于或等于默認(rèn)值小于或等于4096，并且必須是2的冪。

Valgrind的malloc, realloc,等等，在運(yùn)行程序分配的每個(gè)堆塊之前和之后添加填充塊。這種填充塊稱為redzones。redzone大小的默認(rèn)值取決于工具。例如，Memcheck在客戶端分配的每個(gè)塊之前和之后增加并保護(hù)至少16個(gè)字節(jié)。這允許它檢測(cè)最多16個(gè)字節(jié)的塊欠載或超限。

增加紅色區(qū)域大小可以檢測(cè)更大距離的超限，但會(huì)增加Valgrind使用的內(nèi)存量。減少紅區(qū)大小將減少Valgrind所需的內(nèi)存，同時(shí)也降低了檢測(cè)超出/欠載的機(jī)會(huì)，因此不推薦使用。

此選項(xiàng)控制Valgrind對(duì)自修改代碼的檢測(cè)。如果沒(méi)有進(jìn)行任何檢查，當(dāng)程序執(zhí)行一些代碼時(shí)，用新的代碼覆蓋它，并執(zhí)行新的代碼，Valgrind將繼續(xù)執(zhí)行舊代碼的翻譯。這可能會(huì)導(dǎo)致錯(cuò)誤的行為和/或崩潰。

對(duì)于“現(xiàn)代”架構(gòu) - 任何不是x86，amd64或s390x - 的默認(rèn)設(shè)置stack。這是因?yàn)檎_的程序必須采取明確的行動(dòng)來(lái)重新建立代碼修改后的DI緩存一致性。Valgrind遵守并尊重此類行為，結(jié)果是自我修改代碼以零額外成本進(jìn)行透明處理。

對(duì)于x86，amd64和s390x，程序不需要通知硬件所需的DI一致性同步。因此，默認(rèn)是all-non-file覆蓋將代碼生成到匿名（非文件備份）mmap'd區(qū)域的正常情況。

四種可用設(shè)置的含義如下。無(wú)檢測(cè)（none）檢測(cè)堆棧上的自修改代碼（由GCC用于實(shí)現(xiàn)嵌套函數(shù)）（stack），檢測(cè)每個(gè)地方的自修改代碼all，并檢測(cè)除了文件支持的映射之外的其他修改代碼（all-non-file）。

跑步all會(huì)緩慢的下降。運(yùn)行時(shí)none很少加快速度，因?yàn)楹苌俚拇a在大多數(shù)程序中動(dòng)態(tài)生成。該?VALGRIND_DISCARD_TRANSLATIONS客戶端請(qǐng)求是一種替代--smc-check=all?和--smc-check=all-non-file?需要更多的程序員的努力，但允許Valgrind的更快地運(yùn)行您的程序，告訴它準(zhǔn)確翻譯時(shí)需要重新制作。

--smc-check=all-non-file提供了更便宜但更有限的版本--smc-check=all。它會(huì)將檢查添加到不是源于文件支持的內(nèi)存映射的任何翻譯。生成代碼的典型應(yīng)用程序（例如Web瀏覽器中的JIT）將生成代碼到匿名的mmaped區(qū)域，而瀏覽器的“固定”代碼總是存在于文件支持的映射中。?--smc-check=all-non-file?利用這一觀察，限制檢查可能是JIT生成的代碼的開(kāi)銷。

啟用后，Valgrind將從DWARF3調(diào)試信息中讀取有關(guān)內(nèi)聯(lián)函數(shù)調(diào)用的信息。這減慢了Valgrind啟動(dòng)并使其使用更多的內(nèi)存（通常為每個(gè)內(nèi)聯(lián)代碼段，6個(gè)字和空格用于函數(shù)名稱），但它會(huì)導(dǎo)致更多描述性的堆棧跟蹤。對(duì)于3.10.0版本，默認(rèn)情況下僅對(duì)Linux，Android和Solaris目標(biāo)以及僅用于Memcheck，Helgrind和DRD的工具啟用此功能。以下是一些堆棧跟蹤的示例?--read-inline-info=no：

以下是與以下相同的錯(cuò)誤?--read-inline-info=yes：

啟用后，Valgrind將從DWARF3調(diào)試信息中讀取有關(guān)變量類型和位置的信息。這顯著減緩了Valgrind的啟動(dòng)，并使其占用了更多的內(nèi)存，但是對(duì)于可以利用它的工具（Memcheck，Helgrind，DRD），它可能會(huì)導(dǎo)致更精確的錯(cuò)誤消息。例如，以下是Memcheck發(fā)出的一些標(biāo)準(zhǔn)錯(cuò)誤：

以下是與以下相同的錯(cuò)誤?--read-var-info=yes：

作為其主循環(huán)的一部分，Valgrind調(diào)度程序?qū)⑤喸円詸z查某些活動(dòng)（例如外部命令或gdb的某些輸入）是否必須由gdbserver處理。在運(yùn)行給定數(shù)量的基本塊（或略大于給定數(shù)量的基本塊）之后，將進(jìn)行此活動(dòng)輪詢。這個(gè)投票相當(dāng)便宜，所以默認(rèn)值設(shè)置得比較低。如果vgdb無(wú)法使用ptrace系統(tǒng)調(diào)用中斷Valgrind，如果系統(tǒng)調(diào)用中的所有線程（大部分時(shí)間）被阻止，您可能會(huì)進(jìn)一步減少此值。

激活時(shí)，gdbserver會(huì)將Valgrind影子寄存器公開(kāi)到GDB。這樣，可以使用GDB檢查或更改Valgrind影子寄存器的值。隱藏影子寄存器僅適用于GDB 7.1或更高版本。

要與gdb / vgdb通信，Valgrind gdbserver會(huì)創(chuàng)建3個(gè)文件（2個(gè)命名的FIFO和一個(gè)mmap共享內(nèi)存文件）。prefix選項(xiàng)控制創(chuàng)建這些文件的目錄和前綴。

此選項(xiàng)僅在Linux上運(yùn)行Valgrind時(shí)才有用。

libc.so所有程序使用的GNU C庫(kù)（）可能會(huì)為自己的用途分配內(nèi)存。通常，當(dāng)程序結(jié)束時(shí)，它不會(huì)釋放內(nèi)存，因?yàn)長(zhǎng)inux內(nèi)核在進(jìn)程退出時(shí)會(huì)回收所有進(jìn)程資源，所以它只會(huì)減慢速度。

glibc作者意識(shí)到，當(dāng)出口檢查完成時(shí)，這種行為會(huì)導(dǎo)致漏洞檢查器（如Valgrind）錯(cuò)誤地報(bào)告glibc中的泄漏。為了避免這種情況，他們提供了一個(gè)__libc_freeres?專門用于使glibc釋放其分配的所有內(nèi)存的例程。因此，Memcheck嘗試__libc_freeres在退出時(shí)運(yùn)行?。

不幸的是，在一些很舊的glibc版本中，?__libc_freeres足夠錯(cuò)誤的引起分段錯(cuò)誤。這在Red Hat 7.1中尤其明顯。所以這個(gè)選項(xiàng)是為了禁止運(yùn)行而提供的?__libc_freeres。如果您的程序似乎在Valgrind上運(yùn)行良好，但是在出口處出現(xiàn)segfaults，您可能會(huì)發(fā)現(xiàn)?--run-libc-freeres=no修復(fù)盡管可能會(huì)錯(cuò)誤地報(bào)告空間漏洞?libc.so。

此選項(xiàng)僅在運(yùn)行Linux或Solaris C ++程序上的Valgrind時(shí)才有用。

libstdc++.so由g ++編譯的所有C ++程序使用的GNU標(biāo)準(zhǔn)C ++庫(kù)（）可能會(huì)為自己的用途分配內(nèi)存。通常，當(dāng)程序結(jié)束時(shí)，它不會(huì)釋放內(nèi)存，因?yàn)閮?nèi)核在進(jìn)程退出時(shí)會(huì)回收所有進(jìn)程資源，所以它只會(huì)減慢速度。

gcc作者意識(shí)到，當(dāng)在出口處進(jìn)行泄漏檢查時(shí)，此行為會(huì)導(dǎo)致漏洞檢查器（如Valgrind）在libstdc ++中錯(cuò)誤地報(bào)告泄漏。為了避免這種情況，他們提供了一個(gè)__gnu_cxx::__freeres?專門用于使libstdc ++釋放其已分配的所有內(nèi)存的例程。因此，Memcheck嘗試__gnu_cxx::__freeres在退出時(shí)運(yùn)行?。

為了靈活性和不可預(yù)見(jiàn)的問(wèn)題?__gnu_cxx::__freeres，選擇?--run-cxx-freeres=no存在，盡管可能錯(cuò)誤地報(bào)告空間泄漏?libstdc++.so。

通過(guò)Valgrind的其他提示，以非標(biāo)準(zhǔn)或危險(xiǎn)的方式稍微修改模擬行為，可能有助于模擬奇怪的功能。默認(rèn)情況下不啟用任何提示。謹(jǐn)慎使用！目前已知的提示有：

• lax-ioctls:?對(duì)于ioctl處理非常松懈;?唯一的假設(shè)是大小是正確的。寫入時(shí)不需要初始化完整的緩沖區(qū)。沒(méi)有這個(gè)，使用一些設(shè)備驅(qū)動(dòng)程序與大量的奇怪的ioctl命令變得非常麻煩。

• fuse-compatible:?對(duì)可能在FUSE文件系統(tǒng)中阻塞的某些系統(tǒng)調(diào)用啟用特殊處理。在使用一個(gè)線程來(lái)管理FUSE文件系統(tǒng)的多線程程序上運(yùn)行Valgrind并且另一個(gè)線程訪問(wèn)該文件系統(tǒng)時(shí)，這可能是必需的。

• enable-outer:?當(dāng)運(yùn)行程序本身是Valgrind時(shí)，啟用了一些特殊的魔法。

• no-inner-prefix:?禁止>在外部Valgrind運(yùn)行的內(nèi)部Valgrind中，在每個(gè)stdout或stderr輸出行前面打印前綴。當(dāng)在外部/內(nèi)部設(shè)置中運(yùn)行Valgrind回歸測(cè)試時(shí)，這是非常有用的。請(qǐng)注意，前綴>將始終打印在內(nèi)部調(diào)試日志記錄行的前面。

• no-nptl-pthread-stackcache:?這個(gè)提示僅在Linux上運(yùn)行Valgrind時(shí)才有用。

  libpthread.sopthread程序使用的GNU glibc pthread庫(kù)（）維護(hù)一個(gè)pthread棧緩存。當(dāng)pthread終止時(shí)，用于pthread棧的內(nèi)存和一些線程本地存儲(chǔ)相關(guān)數(shù)據(jù)結(jié)構(gòu)并不總是直接釋放。這個(gè)內(nèi)存被保存在高速緩存中（達(dá)到一定的大小），如果啟動(dòng)了一個(gè)新的線程，那么這個(gè)內(nèi)存被重新使用。

  這個(gè)緩存導(dǎo)致helgrind工具在這個(gè)緩存的內(nèi)存上報(bào)告一些錯(cuò)誤的正面競(jìng)爭(zhēng)條件錯(cuò)誤，因?yàn)閔elgrind不了解內(nèi)部glibc緩存同步原語(yǔ)。所以，當(dāng)使用helgrind時(shí)，禁用緩存有助于避免錯(cuò)誤的正面競(jìng)爭(zhēng)條件，特別是當(dāng)使用線程本地存儲(chǔ)變量（例如使用?__thread限定符的變量）時(shí)。

  當(dāng)使用memcheck工具時(shí)，禁用高速緩存可確保glibc處理__thread變量所使用的內(nèi)存在線程終止時(shí)直接釋放。

  注意：Valgrind使用glibc堆棧緩存實(shí)現(xiàn)的一些內(nèi)部知識(shí)以及檢查pthread庫(kù)的調(diào)試信息來(lái)禁用緩存。因此，這種技術(shù)有些脆弱，并且可能對(duì)所有g(shù)libc版本都無(wú)效。這已經(jīng)在各種平臺(tái)上通過(guò)各種glibc版本（例如2.11,2.16,2.18）成功測(cè)試。

• lax-doors:?（僅限Solaris）對(duì)于無(wú)法識(shí)別的門文件描述符，關(guān)于門系統(tǒng)調(diào)用處理非常松懈。不需要在寫入時(shí)初始化完整的緩沖區(qū)。沒(méi)有這一點(diǎn)，使用具有完全專有語(yǔ)義的libdoor（3LIB）功能的程序可能會(huì)報(bào)告大量的誤報(bào)。

該--fair-sched選項(xiàng)控制Valgrind使用的鎖定機(jī)制來(lái)串行線程執(zhí)行。鎖定機(jī)制控制線程的安排方式，不同的設(shè)置在公平性和性能之間進(jìn)行不同的權(quán)衡。有關(guān)Valgrind線程序列化方案及其對(duì)性能和線程調(diào)度的影響的更多詳細(xì)信息，請(qǐng)參閱?計(jì)劃和多線程性能。

• 該值--fair-sched=yes?激活公平的調(diào)度程序。簡(jiǎn)而言之，如果多個(gè)線程準(zhǔn)備運(yùn)行，線程將以輪循方式進(jìn)行安排。該機(jī)制在所有平臺(tái)或Linux版本上都不可用。如果不可用，則使用--fair-sched=yes會(huì)導(dǎo)致Valgrind終止并出現(xiàn)錯(cuò)誤。

  如果您在Valgrind上運(yùn)行交互式多線程程序（例如Web瀏覽器），則可能會(huì)發(fā)現(xiàn)此設(shè)置會(huì)提高整體響應(yīng)能力。

• 該值--fair-sched=try?激活公平調(diào)度（如果在平臺(tái)上可用）。否則會(huì)自動(dòng)回退--fair-sched=no。

• 該值--fair-sched=no激活一個(gè)不能保證線程準(zhǔn)備運(yùn)行的線程之間的公平性，但通常給出最高性能的調(diào)度器。

處理來(lái)自該平臺(tái)的默認(rèn)內(nèi)核的較小變體的系統(tǒng)調(diào)用和ioctl。這對(duì)于在黑客內(nèi)核上運(yùn)行或者支持非標(biāo)準(zhǔn)ioctl的內(nèi)核模塊非常有用。謹(jǐn)慎使用。如果你不明白這個(gè)選項(xiàng)是什么，那么你幾乎肯定不需要它。目前已知的變體是：

• bproc：支持sys_brocx86上的?系統(tǒng)調(diào)用。這是用于在BProc上運(yùn)行的，它是標(biāo)準(zhǔn)Linux的一小部分變體，有時(shí)用于構(gòu)建集群。

• android-no-hw-tls：ARM版Android模擬器的一些版本不提供硬件TLS（線程本地狀態(tài)）寄存器，Valgrind在啟動(dòng)時(shí)崩潰。使用此變體選擇TLS的軟件支持。

• android-gpu-sgx5xx：使用它來(lái)支持在Android設(shè)備上處理PowerVR SGX 5XX系列GPU的專有ioctl。未選擇此項(xiàng)不會(huì)導(dǎo)致穩(wěn)定性問(wèn)題，但可能會(huì)導(dǎo)致Memcheck在程序執(zhí)行GPU特定的ioctl之后報(bào)告錯(cuò)誤的錯(cuò)誤。

• android-gpu-adreno3xx：同樣地，使用它來(lái)支持在Android設(shè)備上處理高通Adreno 3XX系列GPU的專有ioctl。

一些遞歸算法，例如平衡二叉樹(shù)實(shí)現(xiàn)，創(chuàng)建許多不同的堆棧跟蹤，每個(gè)包含循環(huán)的調(diào)用。一個(gè)周期被定義為由零個(gè)或多個(gè)其他程序計(jì)數(shù)器值分隔的兩個(gè)相同的程序計(jì)數(shù)器值。然后，Valgrind可能會(huì)使用大量?jī)?nèi)存來(lái)存儲(chǔ)所有這些堆棧跟蹤。考慮到這種堆棧跟蹤包含重復(fù)的不感興趣的遞歸調(diào)用而不是更有趣的信息，例如已經(jīng)發(fā)起遞歸調(diào)用的函數(shù)，這是一個(gè)很差的內(nèi)存使用。

該選項(xiàng)--merge-recursive-frames=<number>?指示Valgrind檢測(cè)并合并大小最多為<number>?幀的遞歸調(diào)用循環(huán)。當(dāng)檢測(cè)到這樣的循環(huán)時(shí)，Valgrind將堆棧跟蹤中的循環(huán)記錄為唯一的程序計(jì)數(shù)器。

值0（默認(rèn)值）不會(huì)導(dǎo)致遞歸調(diào)用合并。值為1將導(dǎo)致簡(jiǎn)單遞歸算法（例如，階乘實(shí)現(xiàn)）的堆棧跟蹤被折疊。通常需要2的值來(lái)折疊由遞歸算法（如二叉樹(shù)，快速排序等）等產(chǎn)生的堆棧跟蹤。更復(fù)雜的遞歸算法可能需要更高的值。

注意：通過(guò)分析程序計(jì)數(shù)器值來(lái)檢測(cè)遞歸調(diào)用。通過(guò)查看函數(shù)名稱來(lái)檢測(cè)它們。

Valgrind以小碎片（基本塊）翻譯和調(diào)整程序的機(jī)器代碼。翻譯存儲(chǔ)在翻譯高速緩存中，該高速緩存分為多個(gè)部分（扇區(qū)）。如果緩存已滿，則包含最舊的翻譯的扇區(qū)將被清空并重新使用。如果需要這些舊的翻譯，Valgrind必須重新翻譯和重新設(shè)備相應(yīng)的機(jī)器代碼，這是昂貴的。如果程序的“執(zhí)行指令”工作集很大，則通過(guò)減少所需的翻譯次數(shù)，增加扇區(qū)數(shù)量可以提高性能。部門按需分配。一旦分配，一個(gè)部門永遠(yuǎn)不會(huì)被釋放，并占據(jù)相當(dāng)大的空間，--avg-transtab-entry-size?取決于工具和值（Memcheck每個(gè)扇區(qū)大約40 MB）。使用選項(xiàng)--stats=yes來(lái)獲取有關(guān)部門使用的內(nèi)存以及部門分配和回收的準(zhǔn)確信息。

翻譯基本塊的平均大小。該平均尺寸用于確定扇區(qū)的大小。每個(gè)工具提供要使用的默認(rèn)值。如果此默認(rèn)值太小，則翻譯扇區(qū)將變得過(guò)快。如果此默認(rèn)值太大，則翻譯部分內(nèi)存的很大一部分將不被使用。請(qǐng)注意，基本塊平移的平均大小取決于工具，并且可能取決于工具選項(xiàng)。例如，memcheck選項(xiàng)--track-origins=yes?增加了基本塊轉(zhuǎn)換的大小。使用--avg-transtab-entry-size調(diào)整扇區(qū)的大小，既可以獲取內(nèi)存或避免過(guò)多的重譯。

為了避免與某些系統(tǒng)庫(kù)的潛在沖突，Valgrind不會(huì)使用下面的地址空間--aspace-minaddr值，保留它，以防庫(kù)中特別要求該區(qū)域內(nèi)存。所以根據(jù)平臺(tái)，Valgrind猜測(cè)到一些“悲觀”的價(jià)值。在Linux上，默認(rèn)情況下，Valgrind避免使用第一個(gè)64MB，即使這個(gè)完整區(qū)域通常沒(méi)有沖突。您可以使用該選項(xiàng)--aspace-minaddr使您的內(nèi)存饑餓應(yīng)用程序從更多的這種較低的內(nèi)存中受益。另一方面，如果遇到?jīng)_突，增加aspace-minaddr值可能會(huì)解決它。沖突通常會(huì)在地址空間較低的范圍內(nèi)出現(xiàn)mmap故障。address提供的頁(yè)面必須對(duì)齊，并且必須等于或大于0x1000（4KB）。要在平臺(tái)上找到默認(rèn)值，請(qǐng)執(zhí)行以下操作?valgrind -d -d date 2>&1 | grep -i minaddr。已知低于0x10000（64KB）的值會(huì)在某些分布上產(chǎn)生問(wèn)題。

對(duì)于每個(gè)線程，Valgrind需要自己的“私有”堆棧。這些堆棧的默認(rèn)大小在很大程度上是大小尺寸的，因此在大多數(shù)情況下應(yīng)該是足夠的。如果尺寸太小，Valgrind將會(huì)發(fā)生故障。在分裂之前，Valgrind可能在接近極限時(shí)發(fā)出警告。

--valgrind-stacksize如果產(chǎn)生這樣的（不太可能）警告，或者由于分段違規(guī)導(dǎo)致Valgrind死亡，?請(qǐng)使用該選項(xiàng)。在分離大量C ++符號(hào)時(shí)已經(jīng)看到這種分段違例。

如果您的應(yīng)用程序使用許多線程并需要大量?jī)?nèi)存，您可以通過(guò)使用該選項(xiàng)減小這些Valgrind堆棧的大小來(lái)獲得一些內(nèi)存--valgrind-stacksize。

啟用后，Valgrind在某些??情況下會(huì)發(fā)出關(guān)于CPU仿真的警告。這些通常不是有趣的。

當(dāng)soname匹配的共享對(duì)象sonamepatt加載到進(jìn)程中時(shí)，檢查其導(dǎo)出的所有文本符號(hào)。如果沒(méi)有匹配fnnamepatt，打印錯(cuò)誤信息并放棄運(yùn)行。這使得有可能確保運(yùn)行不會(huì)繼續(xù)，除非給定的共享對(duì)象包含特定的函數(shù)名稱。

雙方sonamepatt并?fnnamepatt可以用通常的寫入??和*通配符。例如：":*libc.so*:foo?bar"。您可以使用冒號(hào)以外的字符分隔兩個(gè)模式。第一個(gè)字符和分隔符相同只是重要的。例如，上面的例子也可以寫成"Q*libc.so*Qfoo?bar"。?--require-text-symbol允許多個(gè)標(biāo)志，在這種情況下，將檢查加載到進(jìn)程中的共享對(duì)象。

其目的是支持可靠使用已標(biāo)記的庫(kù)。例如，假設(shè)我們有一個(gè)GCC的版本，?libgomp.so其中已經(jīng)標(biāo)注了注釋以支持Helgrind。將錯(cuò)誤的，未注釋的加載到應(yīng)用程序中是太容易和混亂了?libgomp.so。所以這個(gè)想法是：例如在標(biāo)記的庫(kù)中添加一個(gè)文本符號(hào)annotated_for_helgrind_3_6，然后給出標(biāo)志?--require-text-symbol=:*libgomp*so*:annotated_for_helgrind_3_6?，以便libgomp.so加載時(shí)，Valgrind掃描其符號(hào)表，如果符號(hào)不存在，則運(yùn)行中止，而不是與未標(biāo)記的圖書館保持沉默。請(qǐng)注意，您應(yīng)該將整個(gè)標(biāo)記放在引號(hào)中，以阻止擴(kuò)展*?和?通配符的擴(kuò)展。

加載共享庫(kù)時(shí)，Valgrind會(huì)檢查庫(kù)中必須更換或包裝的函數(shù)。例如，Memcheck用自己的版本替換一些字符串和內(nèi)存函數(shù)（strchr，strlen，strcpy，memchr，memcpy，memmove等）。這樣的替換通常僅在共享庫(kù)中進(jìn)行，其共享庫(kù)的soname匹配預(yù)定義的soname模式（例如?libc.so*在linux上）。默認(rèn)情況下，除了分配函數(shù)（malloc，free，calloc，memalign，realloc，operator new，operator delete等）之外，靜態(tài)鏈接二進(jìn)制或替代庫(kù)不進(jìn)行替換。默認(rèn)情況下，這種分配函數(shù)被截取任何共享庫(kù)或可執(zhí)行文件，如果它們被導(dǎo)出為全局符號(hào)。?這意味著如果找到替換分配庫(kù)（如tcmalloc），則默認(rèn)情況下也會(huì)攔截其函數(shù)。--soname-synonyms在某些情況下，替換可以指定一個(gè)額外的同義詞模式，從而給予更換的靈活性。或防止截取所有公共分配符號(hào)。

目前，這種靈活性只允許使用同義詞的malloc相關(guān)功能somalloc。這個(gè)同義詞可用于執(zhí)行malloc相關(guān)功能的標(biāo)準(zhǔn)替換的所有工具（例如memcheck，massif，drd，helgrind，exp-dhat，exp-sgcheck）。

• 替代的malloc庫(kù)：使用soname?mymalloclib.so（而不是任何其他）替換特定備用庫(kù)中的malloc相關(guān)函數(shù)，給出選項(xiàng)--soname-synonyms=somalloc=mymalloclib.so。可以使用一個(gè)模式來(lái)匹配多個(gè)庫(kù)的聲名。例如，--soname-synonyms=somalloc=*tcmalloc*?將匹配tcmalloc庫(kù)（native，debug，profiled，... tcmalloc變體）的所有變體的soname。

  注意：可以使用readelf實(shí)用程序檢索elf共享庫(kù)的soname。

• 靜態(tài)鏈接庫(kù)中的替換是通過(guò)使用NONE模式來(lái)完成的。例如，如果您鏈??接libtcmalloc.a，并且只想攔截可執(zhí)行文件（和標(biāo)準(zhǔn)庫(kù)）本身的malloc相關(guān)函數(shù)，而不是任何其他共享庫(kù)，則可以給出該選項(xiàng)--soname-synonyms=somalloc=NONE。請(qǐng)注意，NONE模式將匹配主可執(zhí)行文件和任何沒(méi)有soname的共享庫(kù)。

• 要運(yùn)行用于Linux的“默認(rèn)”Firefox版本，其中JEMalloc鏈接到主可執(zhí)行文件，請(qǐng)使用--soname-synonyms=somalloc=NONE。

• 為了僅攔截默認(rèn)系統(tǒng)庫(kù)中的分配符號(hào)，但不能在任何其他共享庫(kù)或定義public malloc或operator new相關(guān)函數(shù)的可執(zhí)行文件中使用不存在的庫(kù)名稱--soname-synonyms=somalloc=nouserintercepts?（如果nouserintercepts可以是任何不存在的庫(kù)名稱）。

• 搜索動(dòng)態(tài)（運(yùn)行時(shí)）鏈接器的共享庫(kù)被排除在搜索全局公共符號(hào)之外，如malloc相關(guān)函數(shù)（由somalloc同義詞標(biāo)識(shí)）。