valgrind只能报告读取uninit var的根本原因吗？

Question

就https://blog.mozilla.org/nnethercote/2009/02/27/eliminating-undefined-values-with-valgrind-the-easy-way/

而言

实际上，当任何操作依赖于因访问未定义变量而导致的先前跳转时，它会为这些操作报告相同的错误。

这有时令人困惑。例如，我可能有一个错误，它依赖于远离这里的if-check，但代码路径确实取决于那个。

鉴于很多valgrind错误，我不确定要启动哪一个。

valgrind是否可以选择报告“root-cause”？

Answer 1

来自Valgrind documentation：

  

要查看有关程序中未初始化数据来源的信息，请使用--track-origins = yes选项。这使得Memcheck的运行速度更慢，但可以更容易地找到未初始化的值错误的根本原因。   

     

- track-originins = [默认：否]   
  控制Memcheck是否跟踪未初始化值的来源。默认情况下，它没有，这意味着虽然它可以告诉您未危险的方式使用未初始化的值，但它无法告诉您未初始化值的来源。这常常使得难以追踪根本问题。

     

设置为yes时，Memcheck会跟踪所有未初始化值的来源。然后，当报告未初始化的值错误时，Memcheck将尝试显示值的来源。原点可以是以下四个位置之一：堆块，堆栈分配，客户端请求或其他各种来源（例如，对brk的调用）。

     

对于源自堆块的未初始化值，Memcheck显示块的分配位置。对于源自堆栈分配的未初始化值，Memcheck可以告诉您哪个函数分配了值，但不超过该值 - 通常它会显示函数左括号的源位置。因此，您应该仔细检查所有函数的局部变量是否已正确初始化。

     

性能开销：原始跟踪很昂贵。它将Memcheck的速度减半，并将内存使用量增加至少100MB，甚至更多。尽管如此，它可以大大减少识别未初始化的值错误的根本原因所需的工作量，因此尽管运行速度较慢，但​​通常也是程序员的生产力获胜。

     

准确性：Memcheck非常准确地跟踪起源。为了避免非常大的空间和时间开销，进行了一些近似。尽管不太可能，Memcheck可能会报告错误的来源，或者无法识别任何来源。

     

请注意，组合--track-originins = yes和--undef-value-errors = no是无意义的。 Memcheck在启动时检查并拒绝此组合。