关于https://blog.mozilla.org/nnethercote/2009/02/27/eliminating-undefined-values-with-valgrind-the-easy-way/valgrind能否报告读取uninit var的根本原因？
实际上，当任何操作依赖于访问未定义变量导致的较早跳转时，它会为这些操作报告相同的错误。
这有时会令人困惑。例如，我可能有一个错误取决于远离这里的if-check，但代码路径实际上取决于那个。
鉴于很多valgrind错误，我不确定哪一个开始。
valgrind是否有选择报告“根本原因”？
要查看未初始化的数据在你的程序中的信息来源，使用--track-起源= yes选项。这使Memcheck运行速度更慢，但可以更轻松地找出未初始化值错误的根本原因。
--track-起源= [默认：无]
控制MEMCHECK是否跟踪未初始化值的原点。默认情况下，它不会，这意味着虽然它可以告诉你一个未初始化的值以危险的方式被使用，但它不能告诉你未初始化的值来自哪里。这通常很难追查根本问题。当设置为yes时，Memcheck会跟踪所有未初始化值的来源。然后，当报告未初始化的值错误时，Memcheck将尝试显示值的来源。源可以是以下四个地方之一：堆块，堆栈分配，客户端请求或其他来源（例如，对brk的调用）。
对于源自堆块的未初始化值，Memcheck会显示块的分配位置。对于源自堆栈分配的未初始化值，Memcheck可以告诉你哪个函数分配了该值，但不超过该值 - 通常它会显示该函数的开始大括号的源位置。所以你应该仔细检查所有函数的局部变量是否被正确初始化。
性能开销：原产地追踪很昂贵。它将Memcheck的速度减半，并将内存使用增加至少100MB，甚至更多。尽管如此，它可以大大减少识别未初始化值错误的根本原因所需的工作量，尽管运行速度更慢，但通常程序员的生产率仍然很高。
准确性：Memcheck相当准确地追踪原点。为了避免非常大的空间和时间开销，进行了一些近似处理。尽管可能性不大，但Memcheck可能会报告不正确的来源，或者无法识别任何来源。
请注意，组合--track-origins = yes和--undef-value-errors = no是无意义的。 Memcheck在启动时检查并拒绝这个组合。