我们将valgrind
用作CI流程的一部分。如果存在某些内存问题,valgrind
必须返回非零代码,并且将报告此事件。这是我们的运行方式:
valgrind --error-exitcode=1 --tool=memcheck --leak-check=full \
--errors-for-leak-kinds=definite --show-leak-kinds=definite \
--track-origins=yes ./some_cgo_application
(...)
==25182== HEAP SUMMARY:
==25182== in use at exit: 2,416,970 bytes in 34,296 blocks
==25182== total heap usage: 83,979 allocs, 49,684 frees, 5,168,335 bytes allocated
==25182==
==25182== LEAK SUMMARY:
==25182== definitely lost: 0 bytes in 0 blocks
==25182== indirectly lost: 0 bytes in 0 blocks
==25182== possibly lost: 3,024 bytes in 7 blocks
==25182== still reachable: 2,413,946 bytes in 34,289 blocks
==25182== of which reachable via heuristic:
==25182== newarray : 520 bytes in 1 blocks
==25182== suppressed: 0 bytes in 0 blocks
==25182== Reachable blocks (those to which a pointer was found) are not shown.
==25182== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==25182==
==25182== For counts of detected and suppressed errors, rerun with: -v
==25182== ERROR SUMMARY: 20 errors from 5 contexts (suppressed: 0 from 0)
当前,我们仅对definitly lost
的内存感兴趣。如果没有块明确丢失,则valgrind
的退出代码应为零。但是,尽管有选项1
,它仍返回--errors-for-leak-kinds=definite --show-leak-kinds=definite
。
echo $?
1
有没有其他选择可以帮助达到预期效果?
答案 0 :(得分:1)
看看--gen-suppressions选项。这样,您可以创建一个文件,该文件告诉valgrind抑制特定于调用堆栈的可能丢失并且仍然可以实现的错误。使用此文件,使用--supressions = filename重新运行valgrind。现在,valgrind($?)的返回值为零。这是一个示例:
valgrind --gen-suppressions=auto --log-file=suppressions.supp ./path/to/program
<open suppressions.supp, delete all lines that are not suppressions, save, and close>
valgrind --suppressions=suppressions.supp ./path/to/program
echo $?
您应该会看到零打印。
这将不会在将来证明您的代码中是否有新的可能丢失和仍然可以到达的错误,但是它将消除当前的错误。如果您想将来验证代码,可以编写一个脚本来分析--gen-suppressions = auto的输出并生成一个新的禁止文件。可以编写该脚本,以便仅对可能丢失的错误以及仍可到达的错误添加抑制,以便您仍会看到自己关心的错误。