Revision: 438
http://www.exim.org/viewvc/pcre2?view=rev&revision=438
Author: ph10
Date: 2015-11-15 18:55:20 +0000 (Sun, 15 Nov 2015)
Log Message:
-----------
Re-arrange valgrind code.
Modified Paths:
--------------
code/trunk/ChangeLog
code/trunk/src/pcre2test.c
Modified: code/trunk/ChangeLog
===================================================================
--- code/trunk/ChangeLog 2015-11-15 05:05:53 UTC (rev 437)
+++ code/trunk/ChangeLog 2015-11-15 18:55:20 UTC (rev 438)
@@ -309,7 +309,10 @@
92. Implement PCRE2_INFO_HASBACKSLASHC.
+93. Re-arrange valgrind support code in pcre2test to avoid spurious reports
+with JIT (possibly caused by SSE2?).
+
Version 10.20 30-June-2015
--------------------------
Modified: code/trunk/src/pcre2test.c
===================================================================
--- code/trunk/src/pcre2test.c 2015-11-15 05:05:53 UTC (rev 437)
+++ code/trunk/src/pcre2test.c 2015-11-15 18:55:20 UTC (rev 438)
@@ -5369,7 +5369,7 @@
the number of code units that will be needed (though the buffer may have to be
extended if replication is involved). */
-needlen = (size_t)(len * code_unit_size);
+needlen = (size_t)((len+1) * code_unit_size);
if (dbuffer == NULL || needlen >= dbuffer_size)
{
while (needlen >= dbuffer_size) dbuffer_size *= 2;
@@ -5658,28 +5658,23 @@
return PR_OK;
}
-/* If we have explicit valgrind support, mark the data from after its end to
-the end of the buffer as unaddressable, so that a read over the end of the
-buffer will be seen by valgrind, even if it doesn't cause a crash. If we're not
-building with valgrind support, at least move the data to the end of the buffer
-so that it might at least cause a crash. If we are using the POSIX interface,
-or testing zero-termination, we must include the terminating zero. */
+/* We now have the subject in dbuffer, with len containing the byte length, and
+ulen containing the code unit length. Move the data to the end of the buffer so
+that a read over the end can be caught by valgrind or other means. If we have
+explicit valgrind support, mark the unused start of the buffer unaddressable.
+If we are using the POSIX interface, or testing zero-termination, we must
+include the terminating zero in the usable data. */
-pp = dbuffer;
c = code_unit_size * (((pat_patctl.control & CTL_POSIX) +
(dat_datctl.control & CTL_ZERO_TERMINATE) != 0)? 1:0);
-
+pp = memmove(dbuffer + dbuffer_size - len - c, dbuffer, len + c);
#ifdef SUPPORT_VALGRIND
- VALGRIND_MAKE_MEM_NOACCESS(dbuffer + len + c, dbuffer_size - (len + c));
-#else
- pp = memmove(pp + dbuffer_size - len - c, pp, len + c);
+ VALGRIND_MAKE_MEM_NOACCESS(dbuffer, dbuffer_size - (len + c));
#endif
-/* We now have len containing the byte length, ulen containing the code unit
-length, and pp pointing to the subject string. POSIX matching is only possible
-in 8-bit mode, and it does not support timing or other fancy features. Some
-were checked at compile time, but we need to check the match-time settings
-here. */
+/* Now pp points to the subject string. POSIX matching is only possible in
+8-bit mode, and it does not support timing or other fancy features. Some were
+checked at compile time, but we need to check the match-time settings here. */
#ifdef SUPPORT_PCRE2_8
if ((pat_patctl.control & CTL_POSIX) != 0)
@@ -5736,7 +5731,7 @@
if (pmatch[i].rm_so >= 0)
{
fprintf(outfile, "%2d: ", (int)i);
- PCHARSV(dbuffer, pmatch[i].rm_so,
+ PCHARSV(pp, pmatch[i].rm_so,
pmatch[i].rm_eo - pmatch[i].rm_so, utf, outfile);
fprintf(outfile, "\n");
if ((i == 0 && (dat_datctl.control & CTL_AFTERTEXT) != 0) ||
@@ -5743,7 +5738,7 @@
(dat_datctl.control & CTL_ALLAFTERTEXT) != 0)
{
fprintf(outfile, "%2d+ ", (int)i);
- PCHARSV(dbuffer, pmatch[i].rm_eo, len - pmatch[i].rm_eo,
+ PCHARSV(pp, pmatch[i].rm_eo, len - pmatch[i].rm_eo,
utf, outfile);
fprintf(outfile, "\n");
}
