]> git.ipfire.org Git - thirdparty/valgrind.git/commitdiff
Merge from trunk, r11491 (tweak docs on "possibly lost" leaks).
authorNicholas Nethercote <njn@valgrind.org>
Tue, 4 Jan 2011 23:49:35 +0000 (23:49 +0000)
committerNicholas Nethercote <njn@valgrind.org>
Tue, 4 Jan 2011 23:49:35 +0000 (23:49 +0000)
git-svn-id: svn://svn.valgrind.org/valgrind/branches/VALGRIND_3_6_BRANCH@11492

docs/xml/FAQ.xml
memcheck/docs/mc-manual.xml

index 983e02adde4228cde678ac65ff031014086247fe..af197f856c6dafc74b52f36152e6d62a2502a10b 100644 (file)
@@ -528,8 +528,9 @@ int main(void)
       </listitem>
       <listitem>
         <para>"possibly lost" means your program is leaking
-        memory, unless you're doing funny things with pointers.
-        This is sometimes reasonable.  Use
+        memory, unless you're doing unusual things with pointers that could
+        cause them to point into the middle of an allocated block;  see the
+        user manual for some possible causes.  Use
         <option>--show-possibly-lost=no</option> if you don't want to see
         these reports.</para>
       </listitem>
index c380fce2b36d802fc7347fcdad98928dc7729a64..8fd88b487bf0cee4b6ccfc6eb8b844f103f2283a 100644 (file)
@@ -401,7 +401,11 @@ three ways we know of that an interior-pointer can occur:</para>
 <itemizedlist>
   <listitem>
     <para>The pointer might have originally been a start-pointer and have been
-    moved along deliberately (or not deliberately) by the program.</para>
+    moved along deliberately (or not deliberately) by the program.  In
+    particular, this can happen if your program uses tagged pointers, i.e.
+    if it uses the bottom one, two or three bits of a pointer, which are
+    normally always zero due to alignment, in order to store extra
+    information.</para>
   </listitem>
     
   <listitem>