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

顯示所有選項的幫助，包括核心和所選工具。如果該選項重復，則相當于給予?--help-debug。

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

顯示Valgrind內核的版本號。工具可以有自己的版本號。有一個方案來確保只有核心版本是已知的工具才能執(zhí)行的工具。這樣做是為了盡量減少由于工具與核心版本不兼容而產生的奇怪問題的機會。

靜默運行，只打印錯誤消息。如果您正在進行回歸測試或有其他自動化測試機器，那么有用。

更冗長?提供有關程序各個方面的更多信息，例如：加載的共享對象，使用的禁用，檢測和執(zhí)行引擎的進度以及有關異常行為的警告。重復該選項會增加詳細程度。

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

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

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

這可以用于從Valgrind上運行的進程樹中修剪不感興趣的分支。但是，使用它時應該小心。當Valgrind跳過跟蹤到可執(zhí)行文件時，它不會跳過跟蹤該可執(zhí)行文件，它也跳過跟蹤任何可執(zhí)行文件的子進程。換句話說，該標志不僅僅是引起跟蹤停止在指定的可執(zhí)行文件 - 它跳過跟蹤任何一個指定的可執(zhí)行文件的整個進程子樹。

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

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

當Valgrind的將提供“gdbserver的”功能?--vgdb=yes或--vgdb=full指定的。這允許外部GNU GDB調試器在Valgrind上運行時控制和調試程序。?--vgdb=full引起顯著的性能開銷，但提供更精確的斷點和觀察點。有關詳細說明，請參閱使用Valgrind的gdbserver和GDB調試程序。

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

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

當Valgrind gdbserver啟用--vgdb=yes或時，使用此選項?--vgdb=full。--vgdb-error報告之后，將為每個錯誤調用Valgrind gdbserver?。您還可以詢問為其他事件調用Valgrind gdbserver，以下列方式之一指定：

• 一個或多個逗號分隔的列表?startup exit valgrindabexit。

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

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

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

• none?為空集。

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

啟用后，每個消息之前都會顯示自啟動以來的已經逝去的時鐘，表示為天，小時，分鐘，秒和毫秒。

指定Valgrind應將其所有消息發(fā)送到指定的文件描述符。默認值2是標準錯誤通道（stderr）。請注意，這可能會干擾客戶端自己使用stderr，因為Valgrind的輸出將與客戶端發(fā)送給stderr的任何輸出交錯。

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

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

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

%%被替換%。

如果%其后的任何其他字符，則導致中止。

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

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

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

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

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

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

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

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

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

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

啟用/禁用C ++名稱的自動解碼（解碼）。默認啟用。啟用后，Valgrind將嘗試將編碼的C ++名稱轉換為接近原始文件的東西。demangler處理由g ++版本2.X，3.X和4.X驅動的符號。

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

指定標識程序位置的堆棧跟蹤中顯示的最大條目數(shù)。請注意，僅使用前四個功能位置（當前功能中的位置，以及其三個直接調用者的位置）常見錯誤。所以這并不影響所報錯誤的總數(shù)。

最大值為500.請注意，較高的設置將使Valgrind運行速度更慢，并占用更多內存，但在使用深嵌套的調用鏈的程序時可能會很有用。

堆棧掃描支持僅在ARM目標上可用。

這些標志通過堆棧掃描啟用和控制堆棧展開。當正常堆棧展開機制 - 使用Dwarf CFI記錄和幀指針跟隨失敗時，堆棧掃描可能能夠恢復堆棧跟蹤。

請注意，堆棧掃描是一種不精確的啟發(fā)式機制，可能會產生非常誤導的結果，或者根本沒有。它只能在緊急情況下使用，正常展開失敗，重要的是仍然有堆棧跟蹤。

堆棧掃描是一種簡單的技術：展開器從堆棧中讀取單詞，并嘗試猜測哪些可能是返回地址，通過檢查它們是否指向ARM或Thumb調用指令。如果是這樣，該詞被添加到回溯。

當函數(shù)調用返回時，會發(fā)生主要的危險，其返回地址被暴露，并且調用一個新的函數(shù)，但新函數(shù)不會覆蓋舊的地址。這樣做的結果是回溯可能包含已經返回的函數(shù)的條目，因此非常混亂。

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

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

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

啟用后，Valgrind停止報告錯誤，總共有10,000,000個，或者1,000個不同的。這是為了阻止錯誤跟蹤機制在具有許多錯誤的程序中成為巨大的性能開銷。

如果Valgrind在運行中報告任何錯誤，則指定返回的替代退出代碼。當設置為默認值（零）時，Valgrind的返回值將始終是正在仿真的進程的返回值。當設置為非零值時，將返回該值，如果Valgrind檢測到任何錯誤。這對于使用Valgrind作為自動化測試套件的一部分非常有用，因為通過檢查返回碼，可以輕松檢測Valgrind報告錯誤的測試用例。

當錯誤輸出為純文本（即XML未使用）時，?--error-markers指示在每個錯誤之前（之后）輸出包含begin（end）字符串的行。

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

請注意，空標記被接受。因此，只能使用開始（或結束）標記。

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

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

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

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

默認情況下，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=。這不是一個特殊情況，只是上述規(guī)則的邏輯后果。

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

默認情況下，Valgrind在幾個眾所周知的路徑中搜索調試對象，例如/usr/lib/debug/。

但是，您可能希望將調試對象放置在任意位置，例如在具有有限本地存儲空間的移動設備上運行Valgrind時的外部存儲。另一個例子可能是您沒有在運行Valgrind的系統(tǒng)上安裝調試對象包的權限的情況。

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

該標志只能指定一次。如果指定多次，則只會保留最后一個實例。

這是在3.9.0版本中引入的一個新的，實驗性的功能。

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

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

如果Valgrind?/w/x/y/zz.so通過使用debuginfo服務器查找debuginfo，它將剝離路徑名組件，并僅zz.so在服務器上請求。反過來，它將僅在其當前工作目錄中查找匹配的debuginfo對象。

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

請注意，即使使用debuginfo服務器，也會執(zhí)行使用GNU debuglink CRC方案來匹配主要和調試對象的檢查。要禁用此類檢查，您還需要指定?--allow-mismatched-debuginfo=yes。

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

當從單獨的debuginfo對象讀取debuginfo時，Valgrind將默認使用GNU debuglink機制檢查main和debuginfo對象是否匹配。這樣保證它不會從過期的debuginfo對象中讀取debuginfo，并且還可以確保Valgrind不會因為不匹配而崩潰。

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

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

設置后yes，Valgrind將在每次顯示錯誤后暫停，并打印行：

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

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

按下Y Ret或?y Ret導致Valgrind寫入此錯誤的抑制。如果您不想再聽到有關該錯誤的信息，可以將其剪切并粘貼到抑制文件中。

設置時all，Valgrind將會針對每個報告的錯誤打印一個抑制，而不會查詢用戶。

此選項對于C ++程序特別有用，因為它根據(jù)需要打印出具有破壞名稱的抑制。

請注意，打印的壓印盡可能具體。您可能希望通過添加通配符到函數(shù)名稱以及使用幀級別的通配符來尋找類似的通配符。通配設備功能強大而靈活，并且經過仔細的編輯，您可能只需少量的壓制即可抑制整個系列的相關錯誤。

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

當使用?--gen-suppressions=yes時，Valgrind將停止，以便在發(fā)生每個錯誤時讀取您的鍵盤輸入。默認情況下，它從標準輸入（stdin）讀取，這對于關閉stdin的程序是有問題的。此選項允許您指定從中讀取輸入的備用文件描述符。

此選項僅在Mac OS X上運行Valgrind時才有用。

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

使用--dsymutil=no，Valgrind將檢測?.dSYM目錄丟失或存在的情況，但不符合關聯(lián)的可執(zhí)行文件，或者.dylib很可能是因為它已過期。在這種情況下，Valgrind會打印一個警告消息，但不采取進一步行動。

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

Valgrind的不會嘗試運行dsymutil在任何可執(zhí)行文件或庫?/usr/，?/bin/，?/sbin/，?/opt/，?/sw/，?/System/，?/Library/或?/Applications/?因為dsymutil總是會在這種情況下失敗。它失敗了，因為這種預安裝的系統(tǒng)組件的debuginfo在任何地方都不可用，也因為它需要這些目錄中的寫入權限。

使用--dsymutil=yes時要小心，因為它會導致預先存在的.dSYM?目錄被靜默刪除并重新創(chuàng)建。還要注意的?dsymutil是相當慢，有的時候太過分了。

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

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

如果Valgrind的調試輸出指示您這樣做，您應該僅考慮使用此選項。在這種情況下，它會告訴您應該指定的新閾值。

通常，在堆棧上分配大型結構是一個壞主意，因為您可以輕松地耗盡堆棧空間，特別是在內存有限的系統(tǒng)上，或者希望支持大量線程，每個都有一個小堆棧，并且還因為錯誤由Memcheck執(zhí)行的檢查對堆分配數(shù)據(jù)比對堆棧分配的數(shù)據(jù)更有效。如果您必須使用此選項，您可能希望考慮將代碼重寫為在堆上分配而不是堆棧。

指定主線程堆棧的大小。

為了簡化內存管理，Valgrind在啟動時保留主線程堆棧的所有空間。這意味著它需要在啟動時知道所需的堆棧大小。

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

如果您需要更大的總堆棧大小，請使用--main-stacksize它來指定它。只需將其設置為您所需的高度，因為保留比您需要的更多空間（即，比您需要的數(shù)百兆字節(jié)）約束了Valgrind的內存分配器，并可能減少Valgrind可以使用的內存總量。這對32位機器來說真的很重要。

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

--main-stacksize只影響程序初始線程的堆棧大小。它對線程棧的大小沒有任何影響，因為Valgrind不會分配它們。

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

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

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

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

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

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

此選項控制Valgrind對自修改代碼的檢測。如果沒有進行任何檢查，當程序執(zhí)行一些代碼時，用新的代碼覆蓋它，并執(zhí)行新的代碼，Valgrind將繼續(xù)執(zhí)行舊代碼的翻譯。這可能會導致錯誤的行為和/或崩潰。

對于“現(xiàn)代”架構 - 任何不是x86，amd64或s390x - 的默認設置stack。這是因為正確的程序必須采取明確的行動來重新建立代碼修改后的DI緩存一致性。Valgrind遵守并尊重此類行為，結果是自我修改代碼以零額外成本進行透明處理。

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

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

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

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

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

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

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

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

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

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

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

此選項僅在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上運行良好，但是在出口處出現(xiàn)segfaults，您可能會發(fā)現(xiàn)?--run-libc-freeres=no修復盡管可能會錯誤地報告空間漏洞?libc.so。

此選項僅在運行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。

通過Valgrind的其他提示，以非標準或危險的方式稍微修改模擬行為，可能有助于模擬奇怪的功能。默認情況下不啟用任何提示。謹慎使用！目前已知的提示有：

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

• fuse-compatible:?對可能在FUSE文件系統(tǒng)中阻塞的某些系統(tǒng)調用啟用特殊處理。在使用一個線程來管理FUSE文件系統(tǒng)的多線程程序上運行Valgrind并且另一個線程訪問該文件系統(tǒng)時，這可能是必需的。

• enable-outer:?當運行程序本身是Valgrind時，啟用了一些特殊的魔法。

• no-inner-prefix:?禁止>在外部Valgrind運行的內部Valgrind中，在每個stdout或stderr輸出行前面打印前綴。當在外部/內部設置中運行Valgrind回歸測試時，這是非常有用的。請注意，前綴>將始終打印在內部調試日志記錄行的前面。

• no-nptl-pthread-stackcache:?這個提示僅在Linux上運行Valgrind時才有用。

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

  這個緩存導致helgrind工具在這個緩存的內存上報告一些錯誤的正面競爭條件錯誤，因為helgrind不了解內部glibc緩存同步原語。所以，當使用helgrind時，禁用緩存有助于避免錯誤的正面競爭條件，特別是當使用線程本地存儲變量（例如使用?__thread限定符的變量）時。

  當使用memcheck工具時，禁用高速緩存可確保glibc處理__thread變量所使用的內存在線程終止時直接釋放。

  注意：Valgrind使用glibc堆棧緩存實現(xiàn)的一些內部知識以及檢查pthread庫的調試信息來禁用緩存。因此，這種技術有些脆弱，并且可能對所有glibc版本都無效。這已經在各種平臺上通過各種glibc版本（例如2.11,2.16,2.18）成功測試。

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

該--fair-sched選項控制Valgrind使用的鎖定機制來串行線程執(zhí)行。鎖定機制控制線程的安排方式，不同的設置在公平性和性能之間進行不同的權衡。有關Valgrind線程序列化方案及其對性能和線程調度的影響的更多詳細信息，請參閱?計劃和多線程性能。

• 該值--fair-sched=yes?激活公平的調度程序。簡而言之，如果多個線程準備運行，線程將以輪循方式進行安排。該機制在所有平臺或Linux版本上都不可用。如果不可用，則使用--fair-sched=yes會導致Valgrind終止并出現(xiàn)錯誤。

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

• 該值--fair-sched=try?激活公平調度（如果在平臺上可用）。否則會自動回退--fair-sched=no。

• 該值--fair-sched=no激活一個不能保證線程準備運行的線程之間的公平性，但通常給出最高性能的調度器。

處理來自該平臺的默認內核的較小變體的系統(tǒng)調用和ioctl。這對于在黑客內核上運行或者支持非標準ioctl的內核模塊非常有用。謹慎使用。如果你不明白這個選項是什么，那么你幾乎肯定不需要它。目前已知的變體是：

• bproc：支持sys_brocx86上的?系統(tǒng)調用。這是用于在BProc上運行的，它是標準Linux的一小部分變體，有時用于構建集群。

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

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

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

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

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

值0（默認值）不會導致遞歸調用合并。值為1將導致簡單遞歸算法（例如，階乘實現(xiàn)）的堆棧跟蹤被折疊。通常需要2的值來折疊由遞歸算法（如二叉樹，快速排序等）等產生的堆棧跟蹤。更復雜的遞歸算法可能需要更高的值。

注意：通過分析程序計數(shù)器值來檢測遞歸調用。通過查看函數(shù)名稱來檢測它們。

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

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

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

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

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

如果您的應用程序使用許多線程并需要大量內存，您可以通過使用該選項減小這些Valgrind堆棧的大小來獲得一些內存--valgrind-stacksize。

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

當soname匹配的共享對象sonamepatt加載到進程中時，檢查其導出的所有文本符號。如果沒有匹配fnnamepatt，打印錯誤信息并放棄運行。這使得有可能確保運行不會繼續(xù)，除非給定的共享對象包含特定的函數(shù)名稱。

雙方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掃描其符號表，如果符號不存在，則運行中止，而不是與未標記的圖書館保持沉默。請注意，您應該將整個標記放在引號中，以阻止擴展*?和?通配符的擴展。

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

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

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

  注意：可以使用readelf實用程序檢索elf共享庫的soname。

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

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

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

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