Increase the threshold above which new errors are not shown from 300

unique / 30000 total to 1000 unique / 100000 total.  Programs are
generally bigger now than 3 years ago.



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

coregrind/m_errormgr.c

@@ -51,16 +51,16 @@
 
 /* After this many different unsuppressed errors have been observed,
    be more conservative about collecting new ones. */
-#define M_COLLECT_ERRORS_SLOWLY_AFTER 50
+#define M_COLLECT_ERRORS_SLOWLY_AFTER 100
 
 /* After this many different unsuppressed errors have been observed,
    stop collecting errors at all, and tell the user their program is
    evidently a steaming pile of camel dung. */
-#define M_COLLECT_NO_ERRORS_AFTER_SHOWN 300
+#define M_COLLECT_NO_ERRORS_AFTER_SHOWN 1000
 
 /* After this many total errors have been observed, stop collecting
    errors at all.  Counterpart to M_COLLECT_NO_ERRORS_AFTER_SHOWN. */
-#define M_COLLECT_NO_ERRORS_AFTER_FOUND 30000
+#define M_COLLECT_NO_ERRORS_AFTER_FOUND 100000
 
 /* The list of error contexts found, both suppressed and unsuppressed.
    Initially empty, and grows as errors are detected. */

docs/valgrind.1

@@ -137,8 +137,8 @@ demangler handles symbols mangled by g++ versions 2.X and 3.X.
 .TP
 .B
 --error-limit=<yes|no> [default: yes]
-When enabled, \fBvalgrind\fP stops reporting errors after 30000 in total,
-or 300 different ones, have been seen. This is to stop the error tracking
+When enabled, \fBvalgrind\fP stops reporting errors after 100000 in total,
+or 1000 different ones, have been seen. This is to stop the error tracking
 machinery from becoming a huge performance overhead in programs with
 many errors.
 

docs/xml/manual-core.xml

@@ -348,10 +348,10 @@ problem.</para>
 expensive one and can become a significant performance overhead
 if your program generates huge quantities of errors.  To avoid
 serious problems here, Valgrind will simply stop collecting
-errors after 300 different errors have been seen, or 30000 errors
+errors after 1000 different errors have been seen, or 100000 errors
 in total have been seen.  In this situation you might as well
 stop your program and fix it, because Valgrind won't tell you
-anything else useful after this.  Note that the 300/30000 limits
+anything else useful after this.  Note that the 1000/100000 limits
 apply after suppressed errors are removed.  These limits are
 defined in <filename>m_errormgr.c</filename> and can be increased
 if necessary.</para>
@@ -769,7 +769,7 @@ errors, e.g. Memcheck, but not Cachegrind.</para>
     [default]</para>
     <para><computeroutput>--error-limit=no</computeroutput></para>
     <para>When enabled, Valgrind stops reporting errors after
-    30000 in total, or 300 different ones, have been seen.  This
+    100000 in total, or 1000 different ones, have been seen.  This
     is to stop the error tracking machinery from becoming a huge
     performance overhead in programs with many errors.</para>
    </listitem>

memcheck/tests/x86/scalar.stderr.exp

@@ -330,9 +330,6 @@ Syscall param mount(data) contains uninitialised byte(s)
    by 0x........: __libc_start_main (in /...libc...)
    by 0x........: ...
 
-More than 50 errors detected.  Subsequent errors
-will still be recorded, but in less detail than before.
-
 Syscall param mount(source) points to unaddressable byte(s)
    at 0x........: syscall (in /...libc...)
    by 0x........: __libc_start_main (in /...libc...)
@@ -708,6 +705,9 @@ Syscall param fcntl(arg) contains uninitialised byte(s)
  55:          __NR_fcntl (GETLK) 1s 0m
 -----------------------------------------------------
 
+More than 100 errors detected.  Subsequent errors
+will still be recorded, but in less detail than before.
+
 Syscall param fcntl(lock) contains uninitialised byte(s)
    at 0x........: syscall (in /...libc...)
    by 0x........: __libc_start_main (in /...libc...)