Update valgrind to fix one problem with 64 bit code, and a regression running...

tools/valgrind/vbug205541.patch

Index: tools/valgrind/vbug205541.patch
===================================================================
--- tools/valgrind/vbug205541.patch	(Revision 0)
+++ tools/valgrind/vbug205541.patch	(Revision 0)
@@ -0,0 +1,21 @@
+# See https://bugs.kde.org/show_bug.cgi?id=205541#c1
+Index: memcheck/mc_main.c
+===================================================================
+--- memcheck/mc_main.c	(revision 10877)

[Timur Iskhodzhanov, 2009/10/21 09:33:28]

why not 10880?

++++ memcheck/mc_main.c	(working copy)
+@@ -3708,7 +3708,14 @@
+    if (rr || ww || xx)
+       MC_(make_mem_defined)(a, len);
+    else
+-      MC_(make_mem_noaccess)(a, len);
++      MC_(make_mem_defined)(a, len);

[Timur Iskhodzhanov, 2009/10/21 09:33:28]

In this case the condition above doesn't make sense.
However, I accept this as a workaround

++      /* State after     mmap(,,PROT_NONE,,,) should match
++       * state after mprotect(,,PROT_NONE):  the operating system
++       * will trap any access, but any subsequent mprotect(,,PROT_R|W|X)
++       * will re-instate the previous V bits [in this case, all valid].
++       * See comment in  mc_pre_clo_init()  re:
++       *       VG_(track_change_mem_mprotect) ( NULL );
++       */
+ }
+ 
+ static