valgrind 能否仅报告读取 uninit var 的根本原因? [英] Can valgrind report only the root-cause of reading uninit var?
问题描述
实际上，当任何操作依赖于由于访问未定义变量而导致的较早跳转时，它会为这些操作报告相同的错误.
Actually when any actions depend on an earlier jump caused by accessing undefined variables, it reports the same error for those actions.
这有时令人困惑.例如，我可能会遇到一个错误，该错误取决于远离此处的 if 检查，但代码路径确实取决于该错误.
This sometimes is confusing. For example, I could have an error that depends on an if-check that is far away from here, but the code path indeed depends on that one.
考虑到很多 valgrind 错误，我不确定该从哪个开始.
Given a lot of valgrind errors, I am not sure which one to start.
valgrind 是否可以选择报告根本原因"?
Does valgrind have an option to report 'root-cause'?
推荐答案
来自 Valgrind 文档:
要查看有关程序中未初始化数据来源的信息，请使用 --track-origins=yes 选项.这使得 Memcheck 运行得更慢，但可以更容易地追踪未初始化值错误的根本原因.
To see information on the sources of uninitialised data in your program, use the --track-origins=yes option. This makes Memcheck run more slowly, but can make it much easier to track down the root causes of uninitialised value errors.
--track-origins= [默认:无]
控制 Memcheck 是否跟踪未初始化值的来源.默认情况下，它不会，这意味着虽然它可以告诉您正在以危险的方式使用未初始化的值，但它无法告诉您未初始化的值来自何处.这通常会使追踪根本问题变得困难.
--track-origins= [default: no]
Controls whether Memcheck tracks the origin of uninitialised values. By default, it does not, which means that although it can tell you that an uninitialised value is being used in a dangerous way, it cannot tell you where the uninitialised value came from. This often makes it difficult to track down the root problem.
设置为 yes 时，Memcheck 会跟踪所有未初始化值的来源.然后，当报告未初始化的值错误时，Memcheck 将尝试显示值的来源.源可以是以下四个位置之一:堆块、堆栈分配、客户端请求或其他杂项来源(例如，对 brk 的调用).
When set to yes, Memcheck keeps track of the origins of all uninitialised values. Then, when an uninitialised value error is reported, Memcheck will try to show the origin of the value. An origin can be one of the following four places: a heap block, a stack allocation, a client request, or miscellaneous other sources (eg, a call to brk).
对于源自堆块的未初始化值，Memcheck 会显示块的分配位置.对于源自堆栈分配的未初始化值，Memcheck 可以告诉您哪个函数分配了该值，但仅此而已——通常它会显示函数左大括号的源位置.因此，您应该仔细检查函数的所有局部变量是否已正确初始化.
For uninitialised values originating from a heap block, Memcheck shows where the block was allocated. For uninitialised values originating from a stack allocation, Memcheck can tell you which function allocated the value, but no more than that -- typically it shows you the source location of the opening brace of the function. So you should carefully check that all of the function's local variables are initialised properly.
性能开销:源头跟踪很昂贵.它将 Memcheck 的速度减半，并将内存使用量增加至少 100MB，甚至更多.尽管如此，它可以大大减少确定未初始化值错误的根本原因所需的工作量，因此尽管运行速度较慢，但通常会提高程序员的生产力.
Performance overhead: origin tracking is expensive. It halves Memcheck's speed and increases memory use by a minimum of 100MB, and possibly more. Nevertheless it can drastically reduce the effort required to identify the root cause of uninitialised value errors, and so is often a programmer productivity win, despite running more slowly.
准确性:Memcheck 非常准确地跟踪起源.为了避免非常大的空间和时间开销，进行了一些近似.Memcheck 可能会报告错误的来源，或者无法识别任何来源.
Accuracy: Memcheck tracks origins quite accurately. To avoid very large space and time overheads, some approximations are made. It is possible, although unlikely, that Memcheck will report an incorrect origin, or not be able to identify any origin.
请注意，组合 --track-origins=yes 和 --undef-value-errors=no 是无意义的.Memcheck 在启动时检查并拒绝此组合.
Note that the combination --track-origins=yes and --undef-value-errors=no is nonsensical. Memcheck checks for and rejects this combination at startup.
这篇关于valgrind 能否仅报告读取 uninit var 的根本原因?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
