Merge r9556 (clarify crash/abort message) from the trunk.

git-svn-id: svn://svn.valgrind.org/valgrind/branches/VALGRIND_3_4_BRANCH@9558

diff --git a/coregrind/m_libcassert.c b/coregrind/m_libcassert.c
index 7669be90ded7b0f3a884f15a463ec6d715350f5f..43bda1cc1d0284f3d6a0b3352506ce3e048d86b0 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 cdf13cfcc24c0774a7c0538e7517bec040c6c7fe..cf3176726d8d7feb18826b5a3ffee738d9b66d08 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 cc7607d097793ab2ec8441ab79ec3145ff7a5dfe..5115265a4c5cb6b46963add1c5a34ea0f534495f 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>