Add an FAQ.

MERGED FROM TRUNK

git-svn-id: svn://svn.valgrind.org/valgrind/branches/VALGRIND_3_2_BRANCH@6327

diff --git a/docs/xml/FAQ.xml b/docs/xml/FAQ.xml
index 51289265184085a7498372723a2616cc02638b2b..720b6470230be14028ac3c4a655d9df4680ac88c 100644 (file)
--- a/docs/xml/FAQ.xml
+++ b/docs/xml/FAQ.xml
@@ -517,6 +517,36 @@ int main(void)
   </answer>
 </qandaentry>
 
+<qandaentry id="faq.undeferrors">
+  <question id="q-undeferrors">
+    <para>Memcheck's uninitialised value errors are hard to track down,
+    because they are often reported some time after they are caused.  Could 
+    Memcheck record a trail of operations to better link the cause to the
+    effect?  Or maybe just eagerly report any copies of uninitialised
+    memory values?</para>
+  </question>
+  <answer id="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 the
+    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 values,
+    this has been suggested multiple times.  Unfortunately, almost all
+    programs legitimately copy uninitialise memory values around (because
+    compilers pad structs to preserve alignment) and eager checking leads to
+    hundreds of false positives.  Therefore Memcheck does not support eager
+    checking at this time.</para>
+  </answer>
+</qandaentry>
+
+
 </qandadiv>