zenithsiz/ftmemsim-valgrind
1
0
Fork 0
mirror of https://github.com/Zenithsiz/ftmemsim-valgrind.git synced 2026-02-04 02:18:37 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

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

Browse Source 
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3719
This commit is contained in:
Nicholas Nethercote 2005-05-15 14:49:24 +00:00
parent 3040604b6d
commit 09cb7d57d1
2 changed files with 32 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
FAQ.txt
View File

@ -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
-----------------------------------------------------------------

18
docs/xml/FAQ.xml
View File

@ -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>