|
From: <sv...@va...> - 2005-05-15 14:50:09
|
Author: njn
Date: 2005-05-15 15:50:05 +0100 (Sun, 15 May 2005)
New Revision: 118
Modified:
trunk/docs/FAQ/faq.unexpected.html
Log:
Add note to FAQ about unloaded shared objects and leak errors.
Modified: trunk/docs/FAQ/faq.unexpected.html
=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/FAQ/faq.unexpected.html 2005-05-12 13:46:24 UTC (rev 117)
+++ trunk/docs/FAQ/faq.unexpected.html 2005-05-15 14:50:05 UTC (rev 118)
@@ -171,6 +171,11 @@
And don't strip symbol tables (programs should be unstripped
unless you run 'strip' on them; some libraries ship
stripped).</p>
+<p>Also, for leak reports involving shared objects, if the shared object=
is
+ unloaded before the program terminates, Valgrind will discard the debu=
g
+ information and the error message will be full of
+ <tt class=3D"literal">???</tt> entries. The workaround here is to avo=
id
+ calling <tt class=3D"literal">dlclose()</tt> on these shared objects.<=
/p>
<p>Also, <tt class=3D"literal">-fomit-frame-pointer</tt> and
<tt class=3D"literal">-fstack-check</tt> can make stack traces
worse.</p>
@@ -202,6 +207,15 @@
by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
by 0x80482CC: ??? (start.S:81)
</pre>
+<p>A leak error message involving an unloaded shared object:</p>
+<pre class=3D"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)
+</pre>
</td>
</tr>
<tr><td colspan=3D"2">=A0</td></tr>
|