關於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在啓動時檢查並拒絕這個組合。