Made the Valgrind abort/crash message clearer about the fact that it can be

caused by heap corruption by the client.  Also clarified the FAQ about this.

Also updated the FAQ about decoding failures a little.

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

diff --git a/coregrind/m_libcassert.c b/coregrind/m_libcassert.c
index e44953cf7fefc7f39eadf91a24e48cd05cc2680c..1d7e5a7d9b1ba78c7c21fc65b9f9a84bd0b1fecf 100644 (file)
--- a/coregrind/m_libcassert.c
+++ b/coregrind/m_libcassert.c
@@ -152,14 +152,19 @@ static void report_and_quit ( const Char* report,
    VG_(pp_StackTrace)  (ips, BACKTRACE_DEPTH);
  
    VG_(show_sched_status)();
-   VG_(printf)("\n");
-   VG_(printf)("Note: see also the FAQ.txt in the source distribution.\n");
-   VG_(printf)("It contains workarounds to several common problems.\n");
-   VG_(printf)("\n");
-   VG_(printf)("If that doesn't help, please report this bug to: %s\n\n", 
-               report);
-   VG_(printf)("In the bug report, send all the above text, the valgrind\n");
-   VG_(printf)("version, and what Linux distro you are using.  Thanks.\n\n");
+   VG_(printf)(
+      "\n"
+      "Note: see also the FAQ in the source distribution.\n"
+      "It contains workarounds to several common problems.\n"
+      "In particular, if Valgrind aborted or crashed after\n"
+      "identifying problems in your program, there's a good chance\n"
+      "that fixing those problems will prevent Valgrind aborting or\n"
+      "crashing, especially if it happened in m_mallocfree.c.\n"
+      "\n"
+      "If that doesn't help, please report this bug to: %s\n\n"
+      "In the bug report, send all the above text, the valgrind\n"
+      "version, and what OS and version you are using.  Thanks.\n\n",
+      report);
    VG_(exit)(1);
 }
 

diff --git a/coregrind/m_mallocfree.c b/coregrind/m_mallocfree.c
index 3c18a4307de2dfce2a6e34a7b2d0bbb737a13cfb..966d965e4d75fc6e129ec7baa2093cc3e51147c7 100644 (file)
--- a/coregrind/m_mallocfree.c
+++ b/coregrind/m_mallocfree.c
@@ -200,23 +200,29 @@ typedef
 
 #define SIZE_T_0x1      ((SizeT)0x1)
 
+static char* probably_your_fault =
+   "This is probably caused by your program erroneously writing past the\n"
+   "end of a heap block and corrupting heap metadata.  If you fix any\n"
+   "invalid writes reported by Memcheck, this assertion failure will\n"
+   "probably go away.  Please try that before reporting this as a bug.\n";
+
 // Mark a bszB as in-use, and not in-use, and remove the in-use attribute.
 static __inline__
 SizeT mk_inuse_bszB ( SizeT bszB )
 {
-   vg_assert(bszB != 0);
+   vg_assert2(bszB != 0, probably_your_fault);
    return bszB & (~SIZE_T_0x1);
 }
 static __inline__
 SizeT mk_free_bszB ( SizeT bszB )
 {
-   vg_assert(bszB != 0);
+   vg_assert2(bszB != 0, probably_your_fault);
    return bszB | SIZE_T_0x1;
 }
 static __inline__
 SizeT mk_plain_bszB ( SizeT bszB )
 {
-   vg_assert(bszB != 0);
+   vg_assert2(bszB != 0, probably_your_fault);
    return bszB & (~SIZE_T_0x1);
 }
 
@@ -238,9 +244,8 @@ SizeT get_bszB_as_is ( Block* b )
    SizeT bszB_lo = *(SizeT*)&b2[0 + hp_overhead_szB()];
    SizeT bszB_hi = *(SizeT*)&b2[mk_plain_bszB(bszB_lo) - sizeof(SizeT)];
    vg_assert2(bszB_lo == bszB_hi, 
-      "Heap block lo/hi size mismatch: lo = %llu, hi = %llu.\n"
-      "Probably caused by overrunning/underrunning a heap block's bounds.\n",
-      (ULong)bszB_lo, (ULong)bszB_hi);
+      "Heap block lo/hi size mismatch: lo = %llu, hi = %llu.\n%s",
+      (ULong)bszB_lo, (ULong)bszB_hi, probably_your_fault);
    return bszB_lo;
 }
 
@@ -267,7 +272,7 @@ static __inline__
 Bool is_inuse_block ( Block* b )
 {
    SizeT bszB = get_bszB_as_is(b);
-   vg_assert(bszB != 0);
+   vg_assert2(bszB != 0, probably_your_fault);
    return (0 != (bszB & SIZE_T_0x1)) ? False : True;
 }
 
@@ -312,7 +317,7 @@ SizeT pszB_to_bszB ( Arena* a, SizeT pszB )
 static __inline__
 SizeT bszB_to_pszB ( Arena* a, SizeT bszB )
 {
-   vg_assert(bszB >= overhead_szB(a));
+   vg_assert2(bszB >= overhead_szB(a), probably_your_fault);
    return bszB - overhead_szB(a);
 }
 

diff --git a/docs/xml/FAQ.xml b/docs/xml/FAQ.xml
index be1ddad74029421ec5fd1d750ad94368e0bf82e9..698ebdb2e19a134712dd119e5c79a1e085535978 100644 (file)
--- a/docs/xml/FAQ.xml
+++ b/docs/xml/FAQ.xml
@@ -142,7 +142,11 @@ collect2: ld returned 1 exit status
 <qandaentry id="faq.bugdeath">
   <question id="q-bugdeath">
     <para>My (buggy) program dies like this:</para>
-<screen>valgrind: m_mallocfree.c:442 (bszW_to_pszW): Assertion 'pszW >= 0' failed.</screen>
+<screen>valgrind: m_mallocfree.c:248 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.</screen>
+    <para>or like this:</para>
+<screen>valgrind: m_mallocfree.c:442 (mk_inuse_bszB): Assertion 'bszB != 0' failed.</screen>
+    <para>or otherwise aborts or crashes in m_mallocfree.c.<para/>
+
   </question>
   <answer id="a-bugdeath">
     <para>If Memcheck (the memory checker) shows any invalid reads,
@@ -162,16 +166,20 @@ collect2: ld returned 1 exit status
 <screen>vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x2E 0x5</screen>
   </question>
   <answer id="a-msgdeath">
-    <para>Older versions did not support some x86 and amd64 instructions,
-    particularly SSE/SSE2/SSE3 instructions.  Try a newer Valgrind; we now
-    support almost all instructions.  If it still breaks, file a bug
+    <para>One possibility is that your program has a bug and erroneously
+    jumps to a non-code address, in which case you'll get a SIGILL signal.
+    Memcheck may issue a warning just before this happens, but it might not
+    if the jump happens to land in addressable memory.</para>
+
+    <para>Another possibility is that Valgrind does not handle the
+    instruction.  If you are using an older Valgrind, a newer version might
+    handle the instruction.  However, all instruction sets have some
+    obscure, rarely used instructions.  Also, on amd64 there are an almost
+    limitless number of combinations of redundant instruction prefixes, many
+    of them undocumented but accepted by CPUs.  So Valgrind will still have
+    decoding failures from time to time.  If this happens, please file a bug
     report.</para>
 
-    <para>Another possibility is that your program has a bug and
-    erroneously jumps to a non-code address, in which case you'll get a
-    SIGILL signal.  Memcheck may issue a warning just before
-    this happens, but it might not if the jump happens to land in
-    addressable memory.</para>
   </answer>
 </qandaentry>