|
From: <sv...@va...> - 2006-10-20 22:17:02
|
Author: njn Date: 2006-10-20 23:16:57 +0100 (Fri, 20 Oct 2006) New Revision: 6326 Log: Add a FAQ. Modified: trunk/docs/xml/FAQ.xml Modified: trunk/docs/xml/FAQ.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/xml/FAQ.xml 2006-10-20 10:00:26 UTC (rev 6325) +++ trunk/docs/xml/FAQ.xml 2006-10-20 22:16:57 UTC (rev 6326) @@ -517,6 +517,36 @@ </answer> </qandaentry> =20 +<qandaentry id=3D"faq.undeferrors"> + <question id=3D"q-undeferrors"> + <para>Memcheck's uninitialised value errors are hard to track down, + because they are often reported some time after they are caused. Co= uld=20 + Memcheck record a trail of operations to better link the cause to th= e + effect? Or maybe just eagerly report any copies of uninitialised + memory values?</para> + </question> + <answer id=3D"a-undeferrors"> + <para>We'd love to improve these errors, but we don't know how to do= it + without huge performance penalties.</para> + + <para>You can use the client request + <computeroutput>VALGRIND_CHECK_VALUE_IS_DEFINED</computeroutput> to = help + track these errors down -- work backwards from the point where the + uninitialised error occurs, checking suspect values until you find t= he + cause. This requires editing, compiling and re-running your program + multiple times, which is a pain, but still easier than debugging the + problem without Memcheck's help.</para> + + <para>As for eager reporting of copies of uninitialised memory value= s, + this has been suggested multiple times. Unfortunately, almost all + programs legitimately copy uninitialise memory values around (becaus= e + compilers pad structs to preserve alignment) and eager checking lead= s to + hundreds of false positives. Therefore Memcheck does not support ea= ger + checking at this time.</para> + </answer> +</qandaentry> + + </qandadiv> =20 =20 |