Add note to FAQ about unloaded shared objects and leak errors.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3719

diff --git a/FAQ.txt b/FAQ.txt
index 625c55cb428cd4f727d644c719ddefce12444d3e..523f03885b98be95b59ea17a075be3be173502a9 100644 (file)
--- a/FAQ.txt
+++ b/FAQ.txt
@@ -200,6 +200,11 @@ If they're not detailed enough, make sure you are compiling with -g to add
 debug information.  And don't strip symbol tables (programs should be
 unstripped unless you run 'strip' on them;  some libraries ship stripped).
 
+Also, for leak reports involving shared objects, if the shared object is
+unloaded before the program terminates, Valgrind will discard the debug
+information and the error message will be full of "???" entries.  The
+workaround here is to avoid calling dlclose() on these shared objects.
+
 Also, -fomit-frame-pointer and -fstack-check can make stack traces worse.
 
 Some example sub-traces:
@@ -231,6 +236,15 @@ Some example sub-traces:
        by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
        by 0x80482CC: ??? (start.S:81)
 
+ A leak error message involving an unloaded shared object:
+
+    84 bytes in 1 blocks are possibly lost in loss record 488 of 713
+       at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132)
+       by 0x1DB63EEB: ???
+       by 0x1DB4B800: ???
+       by 0x1D65E007: ???
+       by 0x8049EE6: main (main.cpp:24)
+
 -----------------------------------------------------------------
 5. Memcheck doesn't find my bug
 -----------------------------------------------------------------

diff --git a/docs/xml/FAQ.xml b/docs/xml/FAQ.xml
index fed9275c6d36fd5390b65011705d9c3a8d1fd832..d4e1d6c88bc2a2f3ddc7ee7e3ac363293b3080ba 100644 (file)
--- a/docs/xml/FAQ.xml
+++ b/docs/xml/FAQ.xml
@@ -284,6 +284,13 @@
   unless you run 'strip' on them; some libraries ship
   stripped).</para>
 
+  <para>Also, for leak reports involving shared objects, if the shared
+  object is unloaded before the program terminates, Valgrind will discard
+  the debug information and the error message will be full of
+  <literal>???</literal> entries.  The workaround here is to avoid calling
+  dlclose() on these shared objects.
+  </para>
+
   <para>Also, <literal>-fomit-frame-pointer</literal> and
   <literal>-fstack-check</literal> can make stack traces
   worse.</para>
@@ -321,6 +328,17 @@ Invalid write of size 1
    by 0x80482CC: ??? (start.S:81)
 </programlisting>
 
+  <para>A leak error message involving an unloaded shared object:</para>
+
+<programlisting>
+84 bytes in 1 blocks are possibly lost in loss record 488 of 713
+   at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132)
+   by 0x1DB63EEB: ???
+   by 0x1DB4B800: ???
+   by 0x1D65E007: ???
+   by 0x8049EE6: main (main.cpp:24)
+</programlisting>
+
  </answer>
 </qandaentry>