You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(9) |
2
(6) |
3
|
|
4
|
5
(3) |
6
(2) |
7
|
8
(6) |
9
(7) |
10
(1) |
|
11
(1) |
12
(2) |
13
(5) |
14
(3) |
15
(2) |
16
(8) |
17
(1) |
|
18
|
19
|
20
(2) |
21
(2) |
22
|
23
(1) |
24
|
|
25
(2) |
26
(2) |
27
(1) |
28
|
29
(1) |
30
|
|
|
From: Murali K. <mur...@gm...> - 2017-06-05 11:21:35
|
Hi, I tried to reproduce the same with the valgrind trunk code and the issue is not observed. Please are the observations from the executions. root@localhost:~$ uname -a Linux localhost 4.4.36-octeon-44-distro.git-v2.35-42-rc #1 SMP Thu Jun 1 07:15:54 UTC 2017 mips64 GNU/Linux root@localhost:~$ root@localhost:~$ /usr/bin/valgrind --version valgrind-3.13.0.SVN root@localhost:~$ root@localhost:~$ valgrind --tool=memcheck ls ==2617== Memcheck, a memory error detector ==2617== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2617== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info ==2617== Command: ls ==2617== ==2617== ==2617== HEAP SUMMARY: ==2617== in use at exit: 144 bytes in 3 blocks ==2617== total heap usage: 4 allocs, 1 frees, 32,960 bytes allocated ==2617== ==2617== LEAK SUMMARY: ==2617== definitely lost: 32 bytes in 2 blocks ==2617== indirectly lost: 112 bytes in 1 blocks ==2617== possibly lost: 0 bytes in 0 blocks ==2617== still reachable: 0 bytes in 0 blocks ==2617== suppressed: 0 bytes in 0 blocks ==2617== Rerun with --leak-check=full to see details of leaked memory ==2617== ==2617== For counts of detected and suppressed errors, rerun with: -v ==2617== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) root@localhost:~$ Apart from the above mentioned ones, i have tried to execute the below command multiple times on the system without any issues observed. "valgrind --tool=memcheck --leak-check=full --show-reachable=yes --error-limit=no --log-file=log.txt ls -l /" Could you please share with us, what has included additionally to the trunk when compared to valgrind-3.12.0.tar.gz. Also please confirm if there is any possibility of getting these additional changes in the form of a patch so that i can use this officially. Thanks & Regards, Muralikrishna CH On Sat, May 27, 2017 at 8:41 PM, Murali Krishna <mur...@gm...> wrote: > Hi Rhys, > > Thanks for the info. > I will test the same with the in-development source and will update the > results soon. > > Thanks & Regards, > Muralikrishna CH > > On Sat, May 27, 2017 at 8:31 PM, Rhys Kidd <rhy...@gm...> wrote: > >> Hello, >> >> Based upon the output of valgrind --version provided you are using >> valgrind 3.12.0. >> >> Whilst this is indeed the most recently released version, the development >> team are well progressed through the next cycle. >> >> valgrind 3.13 is not yet released, however Petar was asking that you test >> the in-development code which we currently host on SVN. It may be that the >> bug you are experiencing is already fixed. >> >> Instructions to get and build the in-development source code version can >> be found here: >> >> http://valgrind.org/downloads/repository.html >> >> Best regards, >> Rhys >> >> >> On Sat, May 27, 2017 at 10:46 AM Murali Krishna <mur...@gm...> >> wrote: >> >>> Hi Petar, >>> >>> Thanks for the response. >>> As mentioned in my earlier email communication, valgrind version which >>> was running on my system and the latest one available(in the >>> valgrind.org) are same. >>> >>> Thanks & Regards, >>> Muralikrishna CH >>> >>> On Fri, May 26, 2017 at 4:38 PM, Petar Jovanovic <mip...@gm...> >>> wrote: >>> >>>> On Fri, May 26, 2017 at 10:48 AM, Murali Krishna >>>> <mur...@gm...> wrote: >>>> > Hi, >>>> > >>>> > As part of running the valgrind in our mips64 linux based system, we >>>> > observed couple of issues. >>>> > When tried to execute "ls" with valgrind, we see that the programme is >>>> > getting crashed. >>>> > >>>> Can you please try the latest SVN code and let us know if the problem >>>> occurs with it? >>>> >>>> Thanks. >>>> >>>> Regards, >>>> Petar >>>> >>> >>> >>> >>> -- >>> >>> Thanks & Regards, >>> Muralikrishna CH >>> >>> ------------------------------------------------------------ >>> ------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______ >>> _________________________________________ >>> Valgrind-developers mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >>> >> > > > -- > > > > > Thanks & Regards, > Muralikrishna CH > > -- Thanks & Regards, Muralikrishna CH |
|
From: <sv...@va...> - 2017-06-02 21:15:13
|
Author: philippe
Date: Fri Jun 2 22:15:04 2017
New Revision: 16435
Log:
Fix 380200 - xtree generated callgrind files refer to files without directory name
Patch from Matthias Schwarzott, slightly modified
Modified:
trunk/NEWS
trunk/coregrind/m_xtree.c
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Fri Jun 2 22:15:04 2017
@@ -247,6 +247,7 @@
379895 clock_gettime does not execute POST syscall wrapper
379925 PPC64, mtffs does not set the FPCC and C bits in the FPSCR correctly
379966 WARNING: unhandled amd64-linux syscall: 313 (finit_module)
+380200 xtree generated callgrind files refer to files without directory name
(3.13.0.RC1: 2 June 2017, vex r3XXX, valgrind r16XXX)
Modified: trunk/coregrind/m_xtree.c
==============================================================================
--- trunk/coregrind/m_xtree.c (original)
+++ trunk/coregrind/m_xtree.c Fri Jun 2 22:15:04 2017
@@ -433,6 +433,10 @@
VgFile* fp = xt_open(outfilename);
DedupPoolAlloc* fnname_ddpa;
DedupPoolAlloc* filename_ddpa;
+ HChar* filename_buf = NULL;
+ UInt filename_buf_size = 0;
+ const HChar* filename_dir;
+ const HChar* filename_name;
if (fp == NULL)
return;
@@ -489,23 +493,43 @@
const HChar* img = img_value(VG_(indexXA)(xt->data, xecu));
- // CALLED_FLF gets the Filename/Line number/Function name for ips[n]
+ // CALLED_FLF gets the Dir+Filename/Line number/Function name for ips[n]
+ // in the variables called_filename/called_linenum/called_fnname.
+ // The booleans called_filename_new/called_fnname_new are set to True
+ // the first time the called_filename/called_fnname are encountered.
+ // The called_filename_nr/called_fnname_nr are numbers identifying
+ // the strings called_filename/called_fnname.
#define CALLED_FLF(n) \
if ((n) < 0 \
|| !VG_(get_filename_linenum)(ips[(n)], \
- &called_filename, \
- NULL, \
+ &filename_name, \
+ &filename_dir, \
&called_linenum)) { \
- called_filename = "UnknownFile???"; \
+ filename_name = "UnknownFile???"; \
called_linenum = 0; \
} \
if ((n) < 0 \
|| !VG_(get_fnname)(ips[(n)], &called_fnname)) { \
called_fnname = "UnknownFn???"; \
} \
+ { \
+ UInt needed_size = VG_(strlen)(filename_dir) + 1 \
+ + VG_(strlen)(filename_name) + 1; \
+ if (filename_buf_size < needed_size) { \
+ filename_buf_size = needed_size; \
+ filename_buf = VG_(realloc)(xt->cc, filename_buf, \
+ filename_buf_size); \
+ } \
+ } \
+ VG_(strcpy)(filename_buf, filename_dir); \
+ if (filename_buf[0] != '\0') { \
+ VG_(strcat)(filename_buf, "/"); \
+ } \
+ VG_(strcat)(filename_buf, filename_name); \
called_filename_nr = VG_(allocStrDedupPA)(filename_ddpa, \
- called_filename, \
+ filename_buf, \
&called_filename_new); \
+ called_filename = filename_buf; \
called_fnname_nr = VG_(allocStrDedupPA)(fnname_ddpa, \
called_fnname, \
&called_fnname_new);
@@ -579,6 +603,7 @@
VG_(fclose)(fp);
VG_(deleteDedupPA)(fnname_ddpa);
VG_(deleteDedupPA)(filename_ddpa);
+ VG_(free)(filename_buf);
}
|
|
From: Julian S. <js...@ac...> - 2017-06-02 15:58:00
|
An RC1 tarball for 3.13.0 is now available at ftp://sourceware.org/pub/valgrind/valgrind-3.13.0.RC1.tar.bz2 (md5sum = a94957849869f1e50a16d60737cfcc29) Please give it a try in configurations that are important for you and report any problems you have, either on this mailing list, or (preferably) via our bug tracker at https://bugs.kde.org/enter_bug.cgi?product=valgrind If nothing critical emerges, a final release will happen on Thursday 15 June. Details of what's new in 3.13.0 are in the NEWS file in the tarball. Some of the highlights are: * Ability to support larger process images and executables * Improved support for compressed debuginfo * C++ demangler update; Rust demangling support * Improved memory use reporting for some tools via the new "XTree" facility * ppc64: ISA 3.0B support * arm32: more v8 instruction support * arm64, mips64, mips32: fixed spins on some cpus * x86, amd64: CET prefix support * amd64: fixes for JIT failure problems on long AVX2 code blocks * OSX 10.12: improved support * Linux: somewhat improved clone handling * The TileGX/Linux port has been removed * Memcheck: improved accuracy with optimised Clang/LLVM generated code * and of course the usual mountain of bug fixes J |
|
From: FEVOTTE F. <fra...@ed...> - 2017-06-02 13:21:45
|
Le jeudi 01 juin 2017 à 13:46 +0200, Roland Mainz a écrit : > It would be nice to be able to "define" the randomness here, e.g. by > providing a pseudo-random-number generator and a command line option > to provide the "seed" value. We are planning to add a command-line switch to provide the seed value (https://github.com/edf-hpc/verrou/issues/3), but I don't think that we will go any further than that. In other words, we don't plan changing the pRNG nor letting the user define it. > Point is that you can actually debug > issues in a deterministic&&repeatable way *IF* they happen. In order to have a deterministic way to perturb results, we have a "farthest" rounding mode, which always rounds in an opposite way to the standard nearest rounding mode (it leaves representable values unchanged, though). This is documented here: http://edf-hpc.github.io/verrou/vr-manual.html#vr-manual.feat.rounding-mode > Another issue is to make sure things like +nan/-nan and NaNs with > payloads work correctly with your tool since there are lots of > applications which use this kind of stuff for error ("error" as in > "error message") propagation. This is a very good point, thanks! I just checked and it appears that Verrou currently preserves NaN values, but sometimes changes an infinite value into a (large but) finite one. Also, NaN payloads are sometimes changed. So there is some work to do here. I opened an issue to handle this: https://github.com/edf-hpc/verrou/issues/4 Thanks for your comment, François -- François FÉVOTTE Research Engineer EDF – R&D – PERICLES I23 (Analysis and Numerical Modeling) 7 boulevard Gaspard Monge 91120 Palaiseau - FRANCE fra...@ed... Phone: +33 1 78 19 44 23 Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. |
|
From: FEVOTTE F. <fra...@ed...> - 2017-06-02 12:31:32
|
Hello, Le jeudi 01 juin 2017 à 11:29 +0000, joh...@si... a écrit : > This is potentially interesting for what I do. Is the documentation at > http://edf-hpc.github.io/verrou/vr-manual.html up to date? Yes, it should be. > Something that would be very useful would be control of the seed of > the random number generator, so that we could repeat and debug cases > that gave strange results. I actually think we had this feature in earlier versions of Verrou, and I'm not sure when and how it disappeared. But I opened an issue on Github (https://github.com/edf-hpc/verrou/issues/3) and will (re)introduce this feature as soon as I can. > The code I work on is a large mathematical modeller, with perhaps > 70,000 functions. Rather than using an exclusion file, it would be > very useful to have an inclusion file as an alternative, where one > could specify only the functions that should be subject to > perturbation. We'd like this because it’s quite difficult to > adequately test various numerical algorithms outside the context of > the modeller. This one is also in our todo list. One way to avoid the problem is to let Verrou generate the whole list of functions it encounters during a test run, and then provide this list as an exclusion list. If you give the full list, nothing will be perturbed; if you comment some functions in the list, only these functions will be perturbed. The generation of exclusion lists is documented here: http://edf-hpc.github.io/verrou/vr-manual.html#idm6262 Thank you for your interest in Verrou. Best regards, François -- François FÉVOTTE Research Engineer EDF – R&D – PERICLES I23 (Analysis and Numerical Modeling) 7 boulevard Gaspard Monge 91120 Palaiseau fra...@ed... Phone: +33 1 78 19 44 23 Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. |
|
From: <sv...@va...> - 2017-06-02 11:44:18
|
Author: sewardj
Date: Fri Jun 2 12:44:06 2017
New Revision: 16434
Log:
-> 3.13.0.RC1 (this time with the correct version number)
Modified:
branches/VALGRIND_3_13_BRANCH/NEWS
branches/VALGRIND_3_13_BRANCH/configure.ac
Modified: branches/VALGRIND_3_13_BRANCH/NEWS
==============================================================================
--- branches/VALGRIND_3_13_BRANCH/NEWS (original)
+++ branches/VALGRIND_3_13_BRANCH/NEWS Fri Jun 2 12:44:06 2017
@@ -248,7 +248,7 @@
379925 PPC64, mtffs does not set the FPCC and C bits in the FPSCR correctly
379966 WARNING: unhandled amd64-linux syscall: 313 (finit_module)
-(3.13.0.RC1: 2 June 2017, vex r3386, valgrind r16432)
+(3.13.0.RC1: 2 June 2017, vex r3386, valgrind r16434)
Modified: branches/VALGRIND_3_13_BRANCH/configure.ac
==============================================================================
--- branches/VALGRIND_3_13_BRANCH/configure.ac (original)
+++ branches/VALGRIND_3_13_BRANCH/configure.ac Fri Jun 2 12:44:06 2017
@@ -8,7 +8,7 @@
##------------------------------------------------------------##
# Process this file with autoconf to produce a configure script.
-AC_INIT([Valgrind],[3.13.RC1],[val...@li...])
+AC_INIT([Valgrind],[3.13.0.RC1],[val...@li...])
AC_CONFIG_SRCDIR(coregrind/m_main.c)
AC_CONFIG_HEADERS([config.h])
AM_INIT_AUTOMAKE([foreign subdir-objects])
|
|
From: James D. <J.H...@ba...> - 2017-06-01 18:39:33
|
Ivo Raisr wrote (I've deleted chunks) > I also wonder if random rounding leads to tremendous understatement or > overstatement of a rounding problem. I can imagine the former, since > random choices might tend to cancel each other out. I could also imagine > the latter, since interval arithmetic (most pessimistic rounding) was > rather incapable of judging the numerical stability of conventional > algorithms. I'm more inclined to bet on the former. It's hard to know without experimenting. But I think I disagree. Consider the classical [Davenport,J.H. & Fischer,H.-C., Manipulation of Expressions. In Improving Floating-Point Programming (ed. P.J.L. Wallis), Wiley, 1990, pp. 149-167.] x*(1-x) with x \in [0,1], where interval arithmetic returns [0,1], while truth is [0,1/4]. This system should return [0,1/4+\epsilon]. I also note that a very similar technique returned good results on classic cases: Parker,D.S.,Pierce,B. & Eggert,P.R., Monte Carlo Arithmetic: How to Gamble with Floating Point and Win. Computing in Science & Engineering 2(2003) 4 pp. 58-68. More generally, there is no single magic bullet for numerical analysis, but MCA has generally been hampered by lack of tools, so a valgrind integration Seems useful. I'd like to play with it. James Davenport Fulbright CyberSecurity Scholar (at New York University) Hebron & Medlock Professor of Information Technology, University of Bath National Teaching Fellow 2014 OpenMath Content Dictionary Editor Director of Studies EPSRC Doctoral Taught Course Centre for HPC Chair, IMU Committee on Electronic Information and Communication Vice-President and Academy Trustee, British Computer Society --------------------------------------------------------------------------- |
|
From: <sv...@va...> - 2017-06-01 17:09:35
|
Author: sewardj
Date: Thu Jun 1 16:44:29 2017
New Revision: 16431
Log:
Update version numbers for 3.13.
Modified:
trunk/NEWS
trunk/configure.ac
trunk/docs/xml/vg-entities.xml
trunk/include/valgrind.h
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Thu Jun 1 16:44:29 2017
@@ -1,4 +1,4 @@
-Release 3.13.0 (?? June 2017)
+Release 3.13.0 (15 June 2017)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.13.0 is a feature release with many improvements and the usual collection of
Modified: trunk/configure.ac
==============================================================================
--- trunk/configure.ac (original)
+++ trunk/configure.ac Thu Jun 1 16:44:29 2017
@@ -8,7 +8,7 @@
##------------------------------------------------------------##
# Process this file with autoconf to produce a configure script.
-AC_INIT([Valgrind],[3.13.0.SVN],[val...@li...])
+AC_INIT([Valgrind],[3.14.0.SVN],[val...@li...])
AC_CONFIG_SRCDIR(coregrind/m_main.c)
AC_CONFIG_HEADERS([config.h])
AM_INIT_AUTOMAKE([foreign subdir-objects])
Modified: trunk/docs/xml/vg-entities.xml
==============================================================================
--- trunk/docs/xml/vg-entities.xml (original)
+++ trunk/docs/xml/vg-entities.xml Thu Jun 1 16:44:29 2017
@@ -2,12 +2,12 @@
<!ENTITY vg-jemail "ju...@va...">
<!ENTITY vg-vemail "val...@va...">
<!ENTITY cl-email "Jos...@gm...">
-<!ENTITY vg-lifespan "2000-2016">
+<!ENTITY vg-lifespan "2000-2017">
<!-- valgrind release + version stuff -->
<!ENTITY rel-type "Release">
-<!ENTITY rel-version "3.13.0.SVN">
-<!ENTITY rel-date "?? ??????? 2017">
+<!ENTITY rel-version "3.13.0">
+<!ENTITY rel-date "15 June 2017">
<!-- where the docs are installed -->
<!ENTITY vg-docs-path "$INSTALL/share/doc/valgrind/html/index.html">
Modified: trunk/include/valgrind.h
==============================================================================
--- trunk/include/valgrind.h (original)
+++ trunk/include/valgrind.h Thu Jun 1 16:44:29 2017
@@ -89,7 +89,7 @@
|| (__VALGRIND_MAJOR__ == 3 && __VALGRIND_MINOR__ >= 6))
*/
#define __VALGRIND_MAJOR__ 3
-#define __VALGRIND_MINOR__ 12
+#define __VALGRIND_MINOR__ 13
#include <stdarg.h>
|
|
From: <sv...@va...> - 2017-06-01 17:09:31
|
Author: sewardj
Date: Thu Jun 1 16:54:54 2017
New Revision: 16433
Log:
-> 3.13.0.RC1
Modified:
branches/VALGRIND_3_13_BRANCH/NEWS
branches/VALGRIND_3_13_BRANCH/configure.ac
Modified: branches/VALGRIND_3_13_BRANCH/NEWS
==============================================================================
--- branches/VALGRIND_3_13_BRANCH/NEWS (original)
+++ branches/VALGRIND_3_13_BRANCH/NEWS Thu Jun 1 16:54:54 2017
@@ -248,7 +248,7 @@
379925 PPC64, mtffs does not set the FPCC and C bits in the FPSCR correctly
379966 WARNING: unhandled amd64-linux syscall: 313 (finit_module)
-(3.13.0.RC1: 2 June 2017, vex r3XXX, valgrind r16XXX)
+(3.13.0.RC1: 2 June 2017, vex r3386, valgrind r16432)
Modified: branches/VALGRIND_3_13_BRANCH/configure.ac
==============================================================================
--- branches/VALGRIND_3_13_BRANCH/configure.ac (original)
+++ branches/VALGRIND_3_13_BRANCH/configure.ac Thu Jun 1 16:54:54 2017
@@ -8,7 +8,7 @@
##------------------------------------------------------------##
# Process this file with autoconf to produce a configure script.
-AC_INIT([Valgrind],[3.14.0.SVN],[val...@li...])
+AC_INIT([Valgrind],[3.13.RC1],[val...@li...])
AC_CONFIG_SRCDIR(coregrind/m_main.c)
AC_CONFIG_HEADERS([config.h])
AM_INIT_AUTOMAKE([foreign subdir-objects])
|
Author: sewardj
Date: Thu Jun 1 16:47:14 2017
New Revision: 16432
Log:
Merge from trunk:
r16430 (Finalise for 3.13)
r16431 (Update version numbers for 3.13.)
Modified:
branches/VALGRIND_3_13_BRANCH/ (props changed)
branches/VALGRIND_3_13_BRANCH/NEWS (contents, props changed)
branches/VALGRIND_3_13_BRANCH/configure.ac
branches/VALGRIND_3_13_BRANCH/docs/internals/3_12_BUGSTATUS.txt
branches/VALGRIND_3_13_BRANCH/docs/xml/vg-entities.xml
branches/VALGRIND_3_13_BRANCH/include/valgrind.h
Modified: branches/VALGRIND_3_13_BRANCH/NEWS
==============================================================================
--- branches/VALGRIND_3_13_BRANCH/NEWS (original)
+++ branches/VALGRIND_3_13_BRANCH/NEWS Thu Jun 1 16:47:14 2017
@@ -1,86 +1,129 @@
-Release 3.13.0 (?? ????????? 201?)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--
-Release 3.13.0 is under development, not yet released.
+Release 3.13.0 (15 June 2017)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-3.13.0 is a feature release with many improvements and the usual
-collection of bug fixes.
+3.13.0 is a feature release with many improvements and the usual collection of
+bug fixes.
-This release supports X86/Linux, AMD64/Linux, ARM32/Linux,
-ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux,
-MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android,
-MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris, X86/MacOSX
-10.10 and AMD64/MacOSX 10.10. There is also preliminary support for
-X86/MacOSX 10.11/12, and AMD64/MacOSX 10.11/12.
+This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux,
+PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux,
+MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android,
+X86/Solaris, AMD64/Solaris and AMD64/MacOSX 10.12.
+
+* ==================== CORE CHANGES ===================
+
+* The translation cache size has been increased to keep up with the demands of
+ large applications. The maximum number of sectors has increased from 24 to
+ 48. The default number of sectors has increased from 16 to 32 on all
+ targets except Android, where the increase is from 6 to 12.
+
+* The amount of memory that Valgrind can use has been increased from 64GB to
+ 128GB. In particular this means your application can allocate up to about
+ 60GB when running on Memcheck.
+
+* Valgrind's default load address has been changed from 0x3800'0000 to
+ 0x5800'0000, so as to make it possible to load larger executables. This
+ should make it possible to load executables of size at least 1200MB.
+
+* A massive spaceleak caused by reading compressed debuginfo files has been
+ fixed. Valgrind should now be entirely usable with gcc-7.0 "-gz" created
+ debuginfo.
+
+* The C++ demangler has been updated.
-* The 'xtree concept' was added in 3.13:
- An xtree is a tree of stacktraces with data associated to the stacktraces.
- This xtree is used by various tools (memcheck, helgrind, massif) to
- report the heap consumption of your program. The xtree reporting
- is controlled by the new options --xtree-memory=none|allocs|full and
- --xtree-memory-file=<file>.
- An heap xtree memory profiling can also be produced on demand using
- the gdbserver monitor command 'xtmemory [<filename>]>'.
- The xtree can be output in 2 formats: 'callgrind format'
- and 'massif format. The existing visualisers for these formats (e.g.
- callgrind_annotate, kcachegrind, ms_print) can be used to visualise
- and analyse these reports.
- Memcheck can also produce leak reports in an xtree callgrind format.
- For more details, read the user manual.
+* Support for demangling Rust symbols has been added.
+
+* A new representation of stack traces, the "XTree", has been added. An XTree
+ is a tree of stacktraces with data associated with the stacktraces. This is
+ used by various tools (Memcheck, Helgrind, Massif) to report on the heap
+ consumption of your program. Reporting is controlled by the new options
+ --xtree-memory=none|allocs|full and --xtree-memory-file=<file>.
+
+ A report can also be produced on demand using the gdbserver monitor command
+ 'xtmemory [<filename>]>'. The XTree can be output in 2 formats: 'callgrind
+ format' and 'massif format. The existing visualisers for these formats (e.g.
+ callgrind_annotate, KCachegrind, ms_print) can be used to visualise and
+ analyse these reports.
+
+ Memcheck can also produce XTree leak reports using the Callgrind file
+ format. For more details, see the user manual.
* ================== PLATFORM CHANGES =================
- - Support for demangling Rust symbols (n-i-bz)
-
- - On linux, clone handling was improved to honour the CLONE_VFORK flag
- and setting a child stack. Note however that CLONE_VFORK | CLONE_VM
- is handled like CLONE_VFORK (so removing CLONE_VM flag).
- Applications that depends on CLONE_VM exact semantic will (still) not work.
+* ppc64: support for ISA 3.0B and various fixes for existing 3.0 support
+
+* amd64: fixes for JIT failure problems on long AVX2 code blocks
+
+* amd64 and x86: support for CET prefixes has been added
+
+* arm32: a few missing ARMv8 instructions have been implemented
- - TileGX/Linux port was removed because the platform is essentially dead.
+* arm64, mips64, mips32: an alternative implementation of Load-Linked and
+ Store-Conditional instructions has been added. This is to deal with
+ processor implementations that implement the LL/SC specifications strictly
+ and as a result cause Valgrind to hang in certain situations. The
+ alternative implementation is automatically enabled at startup, as required.
+ You can use the option --sim-hints=fallback-llsc to force-enable it if you
+ want.
+
+* Support for OSX 10.12 has been improved.
+
+* On Linux, clone handling has been improved to honour CLONE_VFORK that
+ involves a child stack. Note however that CLONE_VFORK | CLONE_VM is handled
+ like CLONE_VFORK (by removing CLONE_VM), so applications that depend on
+ CLONE_VM exact semantics will (still) not work.
+
+* The TileGX/Linux port has been removed because it appears to be both unused
+ and unsupported.
* ==================== TOOL CHANGES ====================
* Memcheck:
+ - Memcheck should give fewer false positives when running optimised
+ Clang/LLVM generated code.
+
- Support for --xtree-memory and 'xtmemory [<filename>]>'.
- New command line options --xtree-leak=no|yes and --xtree-leak-file=<file>
to produce the end of execution leak report in a xtree callgrind format
file.
- - New option 'xtleak' in the memcheck leak_check monitor command, to
- produce the leak report in an xtree file.
+ - New option 'xtleak' in the memcheck leak_check monitor command, to produce
+ the leak report in an xtree file.
* Massif:
- Support for --xtree-memory and 'xtmemory [<filename>]>'.
- - For some workloads (typically, for big applications), Massif
- memory consumption and CPU consumption decreases significantly.
+ - For some workloads (typically, for big applications), Massif memory
+ consumption and CPU consumption has decreased significantly.
* Helgrind:
- Support for --xtree-memory and 'xtmemory [<filename>]>'.
- - addition of client request VALGRIND_HG_GNAT_DEPENDENT_MASTER_JOIN,
- useful for Ada gnat compiled applications.
+ - addition of client request VALGRIND_HG_GNAT_DEPENDENT_MASTER_JOIN, useful
+ for Ada gnat compiled applications.
* ==================== OTHER CHANGES ====================
-* For Valgrind developers: in an outer/inner setup, the outer Valgrind
- will append the inner guest stacktrace to the inner host stacktrace.
- This helps to investigate the errors reported by the outer, when they
- are caused by the inner guest program (such as an inner regtest).
- See README_DEVELOPERS for more info.
-
-* To allow fast detection of callgrind files in desktop environments
- and file managers, the format was extended to have an optional
- first line uniquely identifying the format ("# callgrind format").
- Callgrind creates this line now (also the new xtree functionality).
+* For Valgrind developers: in an outer/inner setup, the outer Valgrind will
+ append the inner guest stacktrace to the inner host stacktrace. This helps
+ to investigate the errors reported by the outer, when they are caused by the
+ inner guest program (such as an inner regtest). See README_DEVELOPERS for
+ more info.
+
+* To allow fast detection of callgrind files by desktop environments and file
+ managers, the format was extended to have an optional first line that
+ uniquely identifies the format ("# callgrind format"). Callgrind creates
+ this line now, as does the new xtree functionality.
* File name template arguments (such as --log-file, --xtree-memory-file, ...)
have a new %n format letter that is replaced by a sequence number.
+* "--version -v" now shows the SVN revision numbers from which Valgrind was
+ built.
+
* ==================== FIXED BUGS ====================
The following bugs have been fixed or resolved. Note that "n-i-bz"
@@ -199,21 +242,14 @@
379504 remove TileGX/Linux port
379525 Support more x86 nop opcodes
379838 disAMode(x86): not an addr!
-379703 PC ISA 3.0 fixes: stxvx, stxv, xscmpexpdp instructions, expected output
- update.
+379703 PC ISA 3.0 fixes: stxvx, stxv, xscmpexpdp instructions
379890 arm: unhandled instruction: 0xEBAD 0x1B05 (sub.w fp, sp, r5, lsl #4)
379895 clock_gettime does not execute POST syscall wrapper
-379925 PPC64, mtffs does not set the FPCC and C bits in the FPSCR register correctly
+379925 PPC64, mtffs does not set the FPCC and C bits in the FPSCR correctly
379966 WARNING: unhandled amd64-linux syscall: 313 (finit_module)
-. - increase usable memory?
-. - get rid of repeated brk message
-. - progress stuff? NO
-. - resize translation caches
-. - expensive interpretation by default? NO
-. - turn on inline debuginfo reading for more tools
-. - make fair-sched the default on Linux
-. - reduce PAUSE hold length
+(3.13.0.RC1: 2 June 2017, vex r3XXX, valgrind r16XXX)
+
Release 3.12.0 (20 October 2016)
Modified: branches/VALGRIND_3_13_BRANCH/configure.ac
==============================================================================
--- branches/VALGRIND_3_13_BRANCH/configure.ac (original)
+++ branches/VALGRIND_3_13_BRANCH/configure.ac Thu Jun 1 16:47:14 2017
@@ -8,7 +8,7 @@
##------------------------------------------------------------##
# Process this file with autoconf to produce a configure script.
-AC_INIT([Valgrind],[3.13.0.SVN],[val...@li...])
+AC_INIT([Valgrind],[3.14.0.SVN],[val...@li...])
AC_CONFIG_SRCDIR(coregrind/m_main.c)
AC_CONFIG_HEADERS([config.h])
AM_INIT_AUTOMAKE([foreign subdir-objects])
Modified: branches/VALGRIND_3_13_BRANCH/docs/internals/3_12_BUGSTATUS.txt
==============================================================================
--- branches/VALGRIND_3_13_BRANCH/docs/internals/3_12_BUGSTATUS.txt (original)
+++ branches/VALGRIND_3_13_BRANCH/docs/internals/3_12_BUGSTATUS.txt Thu Jun 1 16:47:14 2017
@@ -442,8 +442,6 @@
========================================================================
========================================================================
-Mon 6 Mar 21:02:39 CET 2017
-
Wed 10 May 10:24:16 CEST 2017
========================================================================
Modified: branches/VALGRIND_3_13_BRANCH/docs/xml/vg-entities.xml
==============================================================================
--- branches/VALGRIND_3_13_BRANCH/docs/xml/vg-entities.xml (original)
+++ branches/VALGRIND_3_13_BRANCH/docs/xml/vg-entities.xml Thu Jun 1 16:47:14 2017
@@ -2,12 +2,12 @@
<!ENTITY vg-jemail "ju...@va...">
<!ENTITY vg-vemail "val...@va...">
<!ENTITY cl-email "Jos...@gm...">
-<!ENTITY vg-lifespan "2000-2016">
+<!ENTITY vg-lifespan "2000-2017">
<!-- valgrind release + version stuff -->
<!ENTITY rel-type "Release">
-<!ENTITY rel-version "3.13.0.SVN">
-<!ENTITY rel-date "?? ??????? 2017">
+<!ENTITY rel-version "3.13.0">
+<!ENTITY rel-date "15 June 2017">
<!-- where the docs are installed -->
<!ENTITY vg-docs-path "$INSTALL/share/doc/valgrind/html/index.html">
Modified: branches/VALGRIND_3_13_BRANCH/include/valgrind.h
==============================================================================
--- branches/VALGRIND_3_13_BRANCH/include/valgrind.h (original)
+++ branches/VALGRIND_3_13_BRANCH/include/valgrind.h Thu Jun 1 16:47:14 2017
@@ -89,7 +89,7 @@
|| (__VALGRIND_MAJOR__ == 3 && __VALGRIND_MINOR__ >= 6))
*/
#define __VALGRIND_MAJOR__ 3
-#define __VALGRIND_MINOR__ 12
+#define __VALGRIND_MINOR__ 13
#include <stdarg.h>
|
|
From: <sv...@va...> - 2017-06-01 17:09:26
|
Author: sewardj
Date: Thu Jun 1 16:28:45 2017
New Revision: 16430
Log:
Finalise for 3.13.
Modified:
trunk/NEWS
trunk/docs/internals/3_12_BUGSTATUS.txt
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Thu Jun 1 16:28:45 2017
@@ -1,86 +1,129 @@
-Release 3.13.0 (?? ????????? 201?)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--
-Release 3.13.0 is under development, not yet released.
+Release 3.13.0 (?? June 2017)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-3.13.0 is a feature release with many improvements and the usual
-collection of bug fixes.
+3.13.0 is a feature release with many improvements and the usual collection of
+bug fixes.
-This release supports X86/Linux, AMD64/Linux, ARM32/Linux,
-ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux,
-MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android,
-MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris, X86/MacOSX
-10.10 and AMD64/MacOSX 10.10. There is also preliminary support for
-X86/MacOSX 10.11/12, and AMD64/MacOSX 10.11/12.
+This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux,
+PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux,
+MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android,
+X86/Solaris, AMD64/Solaris and AMD64/MacOSX 10.12.
+
+* ==================== CORE CHANGES ===================
+
+* The translation cache size has been increased to keep up with the demands of
+ large applications. The maximum number of sectors has increased from 24 to
+ 48. The default number of sectors has increased from 16 to 32 on all
+ targets except Android, where the increase is from 6 to 12.
+
+* The amount of memory that Valgrind can use has been increased from 64GB to
+ 128GB. In particular this means your application can allocate up to about
+ 60GB when running on Memcheck.
+
+* Valgrind's default load address has been changed from 0x3800'0000 to
+ 0x5800'0000, so as to make it possible to load larger executables. This
+ should make it possible to load executables of size at least 1200MB.
+
+* A massive spaceleak caused by reading compressed debuginfo files has been
+ fixed. Valgrind should now be entirely usable with gcc-7.0 "-gz" created
+ debuginfo.
+
+* The C++ demangler has been updated.
-* The 'xtree concept' was added in 3.13:
- An xtree is a tree of stacktraces with data associated to the stacktraces.
- This xtree is used by various tools (memcheck, helgrind, massif) to
- report the heap consumption of your program. The xtree reporting
- is controlled by the new options --xtree-memory=none|allocs|full and
- --xtree-memory-file=<file>.
- An heap xtree memory profiling can also be produced on demand using
- the gdbserver monitor command 'xtmemory [<filename>]>'.
- The xtree can be output in 2 formats: 'callgrind format'
- and 'massif format. The existing visualisers for these formats (e.g.
- callgrind_annotate, kcachegrind, ms_print) can be used to visualise
- and analyse these reports.
- Memcheck can also produce leak reports in an xtree callgrind format.
- For more details, read the user manual.
+* Support for demangling Rust symbols has been added.
+
+* A new representation of stack traces, the "XTree", has been added. An XTree
+ is a tree of stacktraces with data associated with the stacktraces. This is
+ used by various tools (Memcheck, Helgrind, Massif) to report on the heap
+ consumption of your program. Reporting is controlled by the new options
+ --xtree-memory=none|allocs|full and --xtree-memory-file=<file>.
+
+ A report can also be produced on demand using the gdbserver monitor command
+ 'xtmemory [<filename>]>'. The XTree can be output in 2 formats: 'callgrind
+ format' and 'massif format. The existing visualisers for these formats (e.g.
+ callgrind_annotate, KCachegrind, ms_print) can be used to visualise and
+ analyse these reports.
+
+ Memcheck can also produce XTree leak reports using the Callgrind file
+ format. For more details, see the user manual.
* ================== PLATFORM CHANGES =================
- - Support for demangling Rust symbols (n-i-bz)
-
- - On linux, clone handling was improved to honour the CLONE_VFORK flag
- and setting a child stack. Note however that CLONE_VFORK | CLONE_VM
- is handled like CLONE_VFORK (so removing CLONE_VM flag).
- Applications that depends on CLONE_VM exact semantic will (still) not work.
+* ppc64: support for ISA 3.0B and various fixes for existing 3.0 support
+
+* amd64: fixes for JIT failure problems on long AVX2 code blocks
+
+* amd64 and x86: support for CET prefixes has been added
+
+* arm32: a few missing ARMv8 instructions have been implemented
- - TileGX/Linux port was removed because the platform is essentially dead.
+* arm64, mips64, mips32: an alternative implementation of Load-Linked and
+ Store-Conditional instructions has been added. This is to deal with
+ processor implementations that implement the LL/SC specifications strictly
+ and as a result cause Valgrind to hang in certain situations. The
+ alternative implementation is automatically enabled at startup, as required.
+ You can use the option --sim-hints=fallback-llsc to force-enable it if you
+ want.
+
+* Support for OSX 10.12 has been improved.
+
+* On Linux, clone handling has been improved to honour CLONE_VFORK that
+ involves a child stack. Note however that CLONE_VFORK | CLONE_VM is handled
+ like CLONE_VFORK (by removing CLONE_VM), so applications that depend on
+ CLONE_VM exact semantics will (still) not work.
+
+* The TileGX/Linux port has been removed because it appears to be both unused
+ and unsupported.
* ==================== TOOL CHANGES ====================
* Memcheck:
+ - Memcheck should give fewer false positives when running optimised
+ Clang/LLVM generated code.
+
- Support for --xtree-memory and 'xtmemory [<filename>]>'.
- New command line options --xtree-leak=no|yes and --xtree-leak-file=<file>
to produce the end of execution leak report in a xtree callgrind format
file.
- - New option 'xtleak' in the memcheck leak_check monitor command, to
- produce the leak report in an xtree file.
+ - New option 'xtleak' in the memcheck leak_check monitor command, to produce
+ the leak report in an xtree file.
* Massif:
- Support for --xtree-memory and 'xtmemory [<filename>]>'.
- - For some workloads (typically, for big applications), Massif
- memory consumption and CPU consumption decreases significantly.
+ - For some workloads (typically, for big applications), Massif memory
+ consumption and CPU consumption has decreased significantly.
* Helgrind:
- Support for --xtree-memory and 'xtmemory [<filename>]>'.
- - addition of client request VALGRIND_HG_GNAT_DEPENDENT_MASTER_JOIN,
- useful for Ada gnat compiled applications.
+ - addition of client request VALGRIND_HG_GNAT_DEPENDENT_MASTER_JOIN, useful
+ for Ada gnat compiled applications.
* ==================== OTHER CHANGES ====================
-* For Valgrind developers: in an outer/inner setup, the outer Valgrind
- will append the inner guest stacktrace to the inner host stacktrace.
- This helps to investigate the errors reported by the outer, when they
- are caused by the inner guest program (such as an inner regtest).
- See README_DEVELOPERS for more info.
-
-* To allow fast detection of callgrind files in desktop environments
- and file managers, the format was extended to have an optional
- first line uniquely identifying the format ("# callgrind format").
- Callgrind creates this line now (also the new xtree functionality).
+* For Valgrind developers: in an outer/inner setup, the outer Valgrind will
+ append the inner guest stacktrace to the inner host stacktrace. This helps
+ to investigate the errors reported by the outer, when they are caused by the
+ inner guest program (such as an inner regtest). See README_DEVELOPERS for
+ more info.
+
+* To allow fast detection of callgrind files by desktop environments and file
+ managers, the format was extended to have an optional first line that
+ uniquely identifies the format ("# callgrind format"). Callgrind creates
+ this line now, as does the new xtree functionality.
* File name template arguments (such as --log-file, --xtree-memory-file, ...)
have a new %n format letter that is replaced by a sequence number.
+* "--version -v" now shows the SVN revision numbers from which Valgrind was
+ built.
+
* ==================== FIXED BUGS ====================
The following bugs have been fixed or resolved. Note that "n-i-bz"
@@ -199,21 +242,14 @@
379504 remove TileGX/Linux port
379525 Support more x86 nop opcodes
379838 disAMode(x86): not an addr!
-379703 PC ISA 3.0 fixes: stxvx, stxv, xscmpexpdp instructions, expected output
- update.
+379703 PC ISA 3.0 fixes: stxvx, stxv, xscmpexpdp instructions
379890 arm: unhandled instruction: 0xEBAD 0x1B05 (sub.w fp, sp, r5, lsl #4)
379895 clock_gettime does not execute POST syscall wrapper
-379925 PPC64, mtffs does not set the FPCC and C bits in the FPSCR register correctly
+379925 PPC64, mtffs does not set the FPCC and C bits in the FPSCR correctly
379966 WARNING: unhandled amd64-linux syscall: 313 (finit_module)
-. - increase usable memory?
-. - get rid of repeated brk message
-. - progress stuff? NO
-. - resize translation caches
-. - expensive interpretation by default? NO
-. - turn on inline debuginfo reading for more tools
-. - make fair-sched the default on Linux
-. - reduce PAUSE hold length
+(3.13.0.RC1: 2 June 2017, vex r3XXX, valgrind r16XXX)
+
Release 3.12.0 (20 October 2016)
Modified: trunk/docs/internals/3_12_BUGSTATUS.txt
==============================================================================
--- trunk/docs/internals/3_12_BUGSTATUS.txt (original)
+++ trunk/docs/internals/3_12_BUGSTATUS.txt Thu Jun 1 16:28:45 2017
@@ -442,8 +442,6 @@
========================================================================
========================================================================
-Mon 6 Mar 21:02:39 CET 2017
-
Wed 10 May 10:24:16 CEST 2017
========================================================================
|
|
From: Roland M. <rol...@nr...> - 2017-06-01 11:47:01
|
On Mon, May 29, 2017 at 1:20 PM, FEVOTTE Francois
<fra...@ed...> wrote:
> Dear Valgrind developers,
>
> first, please forgive us if this post is out of place in this list.
>
> We would like to introduce Verrou [1], a floating-point error diagnostics
> tool based on Valgrind. The idea behind the tool is that it replaces all
> floating-point operations by randomly rounded ones (which means that instead
> of always rounding non-representable results to the nearest floating-point
> number, one of the two nearest floating-point numbers is chosen randomly).
It would be nice to be able to "define" the randomness here, e.g. by
providing a pseudo-random-number generator and a command line option
to provide the "seed" value. Point is that you can actually debug
issues in a deterministic&&repeatable way *IF* they happen.
> Instrumented program results thus become realizations of a random variable,
> the dispersion of which gives an estimation of the impact of the
> accumulation of floating-point round-off errors during program execution. In
> the computer arithmetic community, this technique is known as an
> asynchronous CESTAC method, which is a variant of Monte-Carlo arithmetic.
> More details can be found in Verrou's user manual [2].
>
> This work was pursued at EDF R&D [3], but we think such a tool might be of
> broader interest, especially since Valgrind's "Project Suggestions" page
> lists the detection of floating-point inaccuracies as a topic of interest.
Another issue is to make sure things like +nan/-nan and NaNs with
payloads work correctly with your tool since there are lots of
applications which use this kind of stuff for error ("error" as in
"error message") propagation.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) rol...@nr...
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
|
|
From: Ivo R. <iv...@iv...> - 2017-06-01 10:58:51
|
2017-05-29 13:20 GMT+02:00 FEVOTTE Francois <fra...@ed...>: > Dear Valgrind developers, > > first, please forgive us if this post is out of place in this list. > > We would like to introduce Verrou [1], a floating-point error diagnostics > tool based on Valgrind. The idea behind the tool is that it replaces all > floating-point operations by randomly rounded ones (which means that > instead of always rounding non-representable results to the nearest > floating-point number, one of the two nearest floating-point numbers is > chosen randomly). Instrumented program results thus become realizations of > a random variable, the dispersion of which gives an estimation of the > impact of the accumulation of floating-point round-off errors during > program execution. In the computer arithmetic community, this technique is > known as an asynchronous CESTAC method, which is a variant of Monte-Carlo > arithmetic. More details can be found in Verrou's user manual [2]. > > This work was pursued at EDF R&D [3], but we think such a tool might be of > broader interest, especially since Valgrind's "Project Suggestions" page > lists the detection of floating-point inaccuracies as a topic of interest. > We also would like to take the opportunity of this message to thank Josef > Weidendorfer, who kindly helped us getting started with the development of > a new Valgrind tool, back when this project began in 2014. We just released > (under the GPLv2) version 1.0.0 of Verrou, which we believe to be stable > enough for others to use. So please let us know of any comments you might > have about this tool. > Dear François and Bruno, Thank you for sharing information about new Valgrind tool with the Valgrind developers. I am Cc'ing also Valgrind users because it's actually users who will be using this tool. >From the Valgrind (tooling) perspective it looks quite neat. But I know nothing about floating point rounding modes to know how practical it is for finding real issues. So I asked some of my colleagues for their thoughts and comments. Your comments about these are welcome. ---------------------------------------------------------------- Comment #1: My first reaction is that just using random rounding might be considerably less interesting than also being able to do precision bounding. The latter might be able to help with questions like "do I need to switch between float and double?" and stuff like that. I also wonder if random rounding leads to tremendous understatement or overstatement of a rounding problem. I can imagine the former, since random choices might tend to cancel each other out. I could also imagine the latter, since interval arithmetic (most pessimistic rounding) was rather incapable of judging the numerical stability of conventional algorithms. I'm more inclined to bet on the former. Looking at top google hits on Monte Carlo arithmetic makes this stuff sound a little researchy and unproven (old hits, many from the same author), but I didn't look closely. Comment #2: I once tracked down a numerical problem with a SPEC benchmark by modifying the compiler to do arithmetic in both the precision specified by the program and a higher precision, and then to print a warning when they diverged. (Of course, that meant that the higher precision results had to be stored in a table hashed by the address of the lower precision results; also it had to reset the higher precision value when the variable was assigned from some source that didn’t have an associated higher precision value, for example via I/O.) That worked pretty well, although of course it slowed the program down a bit. Comment #3: While I've recently been reading up on design of elementary functions for speed and accuracy, I won't claim to be a master of numerical methods. With that disclaimer, I will say that the idea of "random rounding" makes me uncomfortable, in part because any method which does not give repeatable results creates difficulty for debugging. Also, some types of cumulative numerical instabilities will not be shown by random rounding. On the other hand, the general problem of identifying numerical instability in large applications is a tough problem. If "random rounding" has been shown to help identify some problems, then it could be considered one of several valid numerical stability tests and a useful tool in the numerical analyst's toolbox. Personally, I like the approach of doing test runs of an application at higher precision to see if the results change. That approach is often supported by use of a compiler switch and SW libraries for the higher precision, requiring modest programming effort and a one time investment of slow test runs. I'm sure this tool also requires slow test runs as it talks about repeated runs of different portions of the application to determine the source of maximum round-off variation. For elementary functions, such as those found in libm, there are more rigorous methods than either of the above for proving the worst case error does not exceed defined bounds. Whether this particular tool will become important to customers is unknown. Many more tools are developed than are widely used. It may be determined in part by the 'marketing' of it by its developers. Some approaches get a lot of buzz and then fade away. I class interval arithmetic in that category. Maybe not gone forever, but not driving any major purchase decisions. Others grow and eventually become part of everyone's base expectations (Perl, Java, ...). --------------------------------------------------------------------------- What will happen at this point? 1. I hope we can discuss more about this tool. 2. We can add a link at this page: http://valgrind.org/downloads/variants.html pointing to your tool. 3. If the community agrees that this tool will be worth adding into Valgrind source code repository then you can initiate talks about integrating it. But 1. needs to happen first. Kind regards, Ivosh Raisr |
|
From: <sv...@va...> - 2017-06-01 05:49:57
|
Author: sewardj
Date: Thu Jun 1 06:49:50 2017
New Revision: 16429
Log:
Merge from trunk, r16428:
Back out r16414 (Enable fair scheduling by default on Linux.)
Modified:
branches/VALGRIND_3_13_BRANCH/ (props changed)
branches/VALGRIND_3_13_BRANCH/coregrind/m_options.c
Modified: branches/VALGRIND_3_13_BRANCH/coregrind/m_options.c
==============================================================================
--- branches/VALGRIND_3_13_BRANCH/coregrind/m_options.c (original)
+++ branches/VALGRIND_3_13_BRANCH/coregrind/m_options.c Thu Jun 1 06:49:50 2017
@@ -105,13 +105,8 @@
Bool VG_(clo_debug_dump_line) = False;
Bool VG_(clo_debug_dump_frames) = False;
Bool VG_(clo_trace_redir) = False;
-
-#if defined(VGO_linux)
-enum FairSchedType VG_(clo_fair_sched) = enable_fair_sched;
-#else
-enum FairSchedType VG_(clo_fair_sched) = disable_fair_sched;
-#endif
-
+enum FairSchedType
+ VG_(clo_fair_sched) = disable_fair_sched;
Bool VG_(clo_trace_sched) = False;
Bool VG_(clo_profile_heap) = False;
Int VG_(clo_core_redzone_size) = CORE_REDZONE_DEFAULT_SZB;
|
|
From: <sv...@va...> - 2017-06-01 05:47:05
|
Author: sewardj
Date: Thu Jun 1 06:46:54 2017
New Revision: 16428
Log:
Back out r16414 (Enable fair scheduling by default on Linux.) following
further investigations showing large performance losses in some case, and no
obvious way to fix the problem.
Modified:
trunk/coregrind/m_options.c
Modified: trunk/coregrind/m_options.c
==============================================================================
--- trunk/coregrind/m_options.c (original)
+++ trunk/coregrind/m_options.c Thu Jun 1 06:46:54 2017
@@ -105,13 +105,8 @@
Bool VG_(clo_debug_dump_line) = False;
Bool VG_(clo_debug_dump_frames) = False;
Bool VG_(clo_trace_redir) = False;
-
-#if defined(VGO_linux)
-enum FairSchedType VG_(clo_fair_sched) = enable_fair_sched;
-#else
-enum FairSchedType VG_(clo_fair_sched) = disable_fair_sched;
-#endif
-
+enum FairSchedType
+ VG_(clo_fair_sched) = disable_fair_sched;
Bool VG_(clo_trace_sched) = False;
Bool VG_(clo_profile_heap) = False;
Int VG_(clo_core_redzone_size) = CORE_REDZONE_DEFAULT_SZB;
|