|
From: <sv...@va...> - 2005-05-15 14:49:42
|
Author: njn
Date: 2005-05-15 15:49:24 +0100 (Sun, 15 May 2005)
New Revision: 3719
Modified:
trunk/FAQ.txt
trunk/docs/xml/FAQ.xml
Log:
Add note to FAQ about unloaded shared objects and leak errors.
Modified: trunk/FAQ.txt
=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/FAQ.txt 2005-05-15 03:56:26 UTC (rev 3718)
+++ trunk/FAQ.txt 2005-05-15 14:49:24 UTC (rev 3719)
@@ -200,6 +200,11 @@
debug information. And don't strip symbol tables (programs should be
unstripped unless you run 'strip' on them; some libraries ship stripped=
).
=20
+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=
.
=20
Some example sub-traces:
@@ -231,6 +236,15 @@
by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
by 0x80482CC: ??? (start.S:81)
=20
+ 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
-----------------------------------------------------------------
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 2005-05-15 03:56:26 UTC (rev 3718)
+++ trunk/docs/xml/FAQ.xml 2005-05-15 14:49:24 UTC (rev 3719)
@@ -284,6 +284,13 @@
unless you run 'strip' on them; some libraries ship
stripped).</para>
=20
+ <para>Also, for leak reports involving shared objects, if the shared
+ object is unloaded before the program terminates, Valgrind will discar=
d
+ the debug information and the error message will be full of
+ <literal>???</literal> entries. The workaround here is to avoid calli=
ng
+ 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 @@
by 0x80482CC: ??? (start.S:81)
</programlisting>
=20
+ <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>
=20
|