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
(6) |
|
2
(6) |
3
(9) |
4
(4) |
5
(1) |
6
|
7
|
8
|
|
9
|
10
(2) |
11
(1) |
12
(2) |
13
(4) |
14
(6) |
15
(8) |
|
16
(9) |
17
(5) |
18
(13) |
19
(6) |
20
(15) |
21
(17) |
22
(19) |
|
23
(2) |
24
(4) |
25
(2) |
26
(10) |
27
(6) |
28
(9) |
29
(3) |
|
30
|
|
|
|
|
|
|
|
From: Mark W. <ma...@kl...> - 2023-04-03 22:26:53
|
On Tue, Apr 04, 2023 at 07:42:15AM +1000, Nicholas Nethercote wrote: > On Tue, 4 Apr 2023 at 07:08, Mark Wielaard <ma...@kl...> wrote: > > > > > > I looked at some of the failing builders, they all fail like this: > > > > > > > [...] > > > > integration > > > > -FAIL: qawo(f456) elist (7.25063790881233303e-15 observed vs > > 7.25922435194575979e-15 expected) > > > > interpolation > > > > [...] > > > > rng > > > > +FAIL: random32-bsd, 10000 steps (852261210 observed vs 1663114331 > > expected) > > > > +FAIL: random64-bsd, 10000 steps (210970120 observed vs 864469165 > > expected) > > > > +FAIL: random32-libc5, 10000 steps (367802360 observed vs 1967452027 > > expected) > > > > +FAIL: random64-libc5, 10000 steps (221021662 observed vs 2106639801 > > expected) > > > > roots > > > > So the (now new) failures are the random tests. > > > > And it looks like `qawo` has changed to passing, too? qawo was only failing on i386. so the logic in the makefile assumes everything is passing and if not, that it must be a run on i386 where there is only one difference, the FAIL: qawo. See the (still passing) i386 run: https://builder.sourceware.org/buildbot/#/builders/40/builds/310/steps/6/logs/stdio Cheers, Mark |
|
From: Nicholas N. <nj...@so...> - 2023-04-03 22:07:45
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=3d0d7a19248c9eea026528109e5f0870b86065ff commit 3d0d7a19248c9eea026528109e5f0870b86065ff Author: Nicholas Nethercote <n.n...@gm...> Date: Tue Apr 4 08:06:41 2023 +1000 Some tiny README fixes. Diff: --- README | 8 +++----- README_DEVELOPERS | 14 ++++++++------ 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/README b/README index ddbb85689d..4ac3ace5eb 100644 --- a/README +++ b/README @@ -1,4 +1,3 @@ - Release notes for Valgrind ~~~~~~~~~~~~~~~~~~~~~~~~~~ If you are building a binary package of Valgrind for distribution, @@ -22,10 +21,9 @@ use Valgrind to build new tools. The Valgrind distribution currently includes six production-quality tools: a memory error detector, two thread error detectors, a cache and branch-prediction profiler, a call-graph generating cache and -branch-prediction profiler, and a heap profiler. It also includes -three experimental tools: a heap/stack/global array overrun detector, -a different kind of heap profiler, and a SimPoint basic block vector -generator. +branch-prediction profiler, and two heap profilers. It also includes +two experimental tools: a heap/stack/global array overrun detector, +and a SimPoint basic block vector generator. Valgrind is closely tied to details of the CPU, operating system and to a lesser extent, compiler and basic C libraries. This makes it difficult diff --git a/README_DEVELOPERS b/README_DEVELOPERS index 4ed21a561b..9c04763d47 100644 --- a/README_DEVELOPERS +++ b/README_DEVELOPERS @@ -3,6 +3,7 @@ Building and installing it To build/install from the GIT repository or from a distribution tarball, refer to the section with the same name in README. + Building and not installing it ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To run Valgrind without having to install it, run coregrind/valgrind @@ -91,12 +92,12 @@ to a try branch will be build by the buildbot at builder.sourceware.org https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try If you want to try a commit you can push to a special named try branch -(users/<your-user-name>/try-<topic>) as follows: +(users/<your-user-name>/try-<your-branch>) as follows: - git checkout -b frob + git checkout -b <your-branch> ...hack, hack, hack... OK, looks good to submit git commit -a -m "Awesome hack" - git push origin frob:users/username/try-frob + git push origin <your-branch>:users/<your-user-name>/try-<your-branch> When all builders have build your patch the buildbot will sent you (or actually the patch author) an email telling you if any builds failed and @@ -105,7 +106,8 @@ https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try Afterwards you can delete the branch again: - git push origin :users/username/try-frob + git push origin :users/username/try-<your-branch> + Debugging Valgrind with GDB ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -178,7 +180,7 @@ A different and possibly easier way is as follows: Self-hosting ~~~~~~~~~~~~ -This section explains : +This section explains: (A) How to configure Valgrind to run under Valgrind. Such a setup is called self hosting, or outer/inner setup. (B) How to run Valgrind regression tests in a 'self-hosting' mode, @@ -272,7 +274,7 @@ it contains the detected race conditions. The file tests/outer_inner.supp contains suppressions for the irrelevant or benign errors found in the inner. -An regression test running in the inner (e.g. memcheck/tests/badrw) will +A regression test running in the inner (e.g. memcheck/tests/badrw) will cause the inner to report an error, which is expected and checked as usual when running the regtests in an outer/inner setup. However, the outer will often also observe an error, e.g. a jump |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-03 21:42:36
|
On Tue, 4 Apr 2023 at 07:08, Mark Wielaard <ma...@kl...> wrote: > > > I looked at some of the failing builders, they all fail like this: > > > > > [...] > > > integration > > > -FAIL: qawo(f456) elist (7.25063790881233303e-15 observed vs > 7.25922435194575979e-15 expected) > > > interpolation > > > [...] > > > rng > > > +FAIL: random32-bsd, 10000 steps (852261210 observed vs 1663114331 > expected) > > > +FAIL: random64-bsd, 10000 steps (210970120 observed vs 864469165 > expected) > > > +FAIL: random32-libc5, 10000 steps (367802360 observed vs 1967452027 > expected) > > > +FAIL: random64-libc5, 10000 steps (221021662 observed vs 2106639801 > expected) > > > roots > > So the (now new) failures are the random tests. > And it looks like `qawo` has changed to passing, too? Nick |
|
From: Mark W. <ma...@kl...> - 2023-04-03 21:08:50
|
Hi Nick, On Mon, Apr 03, 2023 at 08:04:37PM +1000, Nicholas Nethercote wrote: > On Sun, 2 Apr 2023 at 08:55, Mark Wielaard <ma...@kl...> wrote: > > Hopefully we can figure out why the auxtests fail now on some of these > > setups. > > > > What are the auxtests? I don't remember hearing about them and a Google > search didn't turn up anything helpful. It is what you get when you do make auxchecks which is a target inside the auxprogs directory. See #---------------------------------------------------------------------------- # Auxiliary testsuits #---------------------------------------------------------------------------- auxchecks: gsl-check It basically downloads and builds the (very old) GNU Scientific Library 1.6. Then it runs the testsuite under valgrind. > I looked at some of the failing builders, they all fail like this: > > > for gsl_test in block cblas cdf cheb combination complex const deriv dht diff eigen err fft fit histogram ieee-utils integration interpolation linalg matrix min monte multifit multimin multiroots ntuple ode-initval permutation poly qrng rng roots sort specfunc statistics sum sys vector wavelet; do echo $gsl_test; done \ > > | cmp - /home/builder/valgrind-auxtests/gsl-build-g-O3/valgrind-gsl.out || \ > > diff -u /home/builder/shared/bb1-2/worker/valgrind-debian-testing-x86_64/build/auxprogs/gsl-1.6.out.x86.exp \ > > /home/builder/valgrind-auxtests/gsl-build-g-O3/valgrind-gsl.out > > - /home/builder/valgrind-auxtests/gsl-build-g-O3/valgrind-gsl.out differ: char 226, line 32 > > --- /home/builder/shared/bb1-2/worker/valgrind-debian-testing-x86_64/build/auxprogs/gsl-1.6.out.x86.exp 2022-08-09 19:45:48.726405142 +0000 > > +++ /home/builder/valgrind-auxtests/gsl-build-g-O3/valgrind-gsl.out 2023-04-02 13:43:46.609646296 +0000 > > @@ -15,7 +15,6 @@ > > histogram > > ieee-utils > > integration > > -FAIL: qawo(f456) elist (7.25063790881233303e-15 observed vs 7.25922435194575979e-15 expected) > > interpolation > > linalg > > matrix > > @@ -30,6 +29,10 @@ > > poly > > qrng > > rng > > +FAIL: random32-bsd, 10000 steps (852261210 observed vs 1663114331 expected) > > +FAIL: random64-bsd, 10000 steps (210970120 observed vs 864469165 expected) > > +FAIL: random32-libc5, 10000 steps (367802360 observed vs 1967452027 expected) > > +FAIL: random64-libc5, 10000 steps (221021662 observed vs 2106639801 expected) > > roots > > sort > > specfunc > > make[1]: Leaving directory '/home/builder/shared/bb1-2/worker/valgrind-debian-testing-x86_64/build/auxprogs' > > > > I don't know why it's comparing against `gsl-1.6.out.x86.exp` even on > x86-64, arm64, ppc64le, and so on. That is explained in the auxprogs/Makefile just above the gsl-check target: # We hope all tests PASS (so don't produce output except for the test names). # But on x86 we get one FAIL, so that is "fine" too. # We currently don't check stderr, but we probably should. So the (now new) failures are the random tests. Cheers, Mark |
|
From: Floyd, P. <pj...@wa...> - 2023-04-03 16:12:30
|
On 03/04/2023 11:29, Nicholas Nethercote wrote: > Hi, > > > Therefore, I propose changing the default to `--cache-sim=no`. Does > anyone have any objections to this? > No objection. I tend to use Linux perf at work because the things we want to optimize have runtimes of hours to days with 8 threads. A+ Paul |
|
From: Floyd, P. <pj...@wa...> - 2023-04-03 16:04:19
|
On 02/04/2023 00:55, Mark Wielaard wrote: > > So should we make a new check target that runs a subset of make > regtests? Or maybe have a "ci mode" for regtests? So you would run > CI_MODE=true make regtests and it would skip any vgtest that has > prereq: test -z "$CI_MODE" > > And then add make regtests to the ci and try buildbots? How long does make regtest take, compared to make auxtests? There is a patchset in bugzilla to get regtest to run in parallel https://bugs.kde.org/show_bug.cgi?id=319307 that could speed things up. If we do want to have a CI mode the way I'd do it is to add an option to tests/vg_regtest to run tests from a file containing a list and then put a list of tests in tests/ci_list It would be good to do more kinds of testing. Adding unit tests would be a bit of a challenge - we'd probably have to write out own VG_(unit_test) framework. We could do a bit of fuzz testing on the command line interface, but probably not much with the testcases. Fuzzing the testcase source files would be more of a test of the compiler. Maybe ELF fuzzing e.g., https://github.com/IOActive/Melkor_ELF_Fuzzer. On the larger scale, it would be good to be able to run more 3rd party suites with Valgrind. I've run the FreeBSD libc tests by simply running everything under Valgrind. Can we do something similar for glibc or other popular libraries? A+ Paul |
|
From: Roger L. <ro...@at...> - 2023-04-03 10:33:02
|
Hi, Whether or not you do this, it might be worth updating the description on https://valgrind.org/info/tools.html with some of the information in your email. Cheers, Roger On Mon, 3 Apr 2023 at 10:30, Nicholas Nethercote <n.n...@gm...> wrote: > Hi, > > Cachegrind has an option `--cache-sim`. > > If you run with `--cache-sim=yes` (the default) it tells it Cachegrind to > do a full cache simulation with lots of events: Ir, I1mr, ILmr, Dr, D1mr, > DLmr, Dw, D1mw, DLmw. > > If you run with `--cache-sim=no` then the cache simulation is disabled and > you just get one event: Ir. (This is "instruction cache reads", which is > equivalent to "instructions executed".) > > I have been using `--cache-sim=no` almost exclusively for a long time. The > cache simulation done by Valgrind is an approximation of the memory > hierarchy of a 2002 AMD Athlon processor. Its accuracy for a modern memory > hierarchy with three levels of cache, prefetching, non-LRU replacement, and > who-knows-what-else is likely to be low. If you want to accurately know > about cache behaviour you'd be much better off using hardware counters via > `perf` or some other profiler. > > But `--cache-sim=no` is still very useful because instruction execution > counts are still very useful. > > Therefore, I propose changing the default to `--cache-sim=no`. Does anyone > have any objections to this? > > Thanks. > > Nick > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-03 10:04:56
|
On Sun, 2 Apr 2023 at 08:55, Mark Wielaard <ma...@kl...> wrote: > > So for the original buildbot CI I set it up to only run the auxtests > (that is build gsl and run the testsuite under valgrind). This used to > work on all setups, but after a gcc (or glibc?) update some setups > started failing as you can see at: > https://builder.sourceware.org/buildbot/#/builders?tags=valgrind > > For the try builders I took out the now failing builders > (debian-testing-x86_64, fedora-arm64, fedora-x86_64, ibm-power10, > opensusetw-x86_64 and rawhide-x86_64). > https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try > > Hopefully we can figure out why the auxtests fail now on some of these > setups. > What are the auxtests? I don't remember hearing about them and a Google search didn't turn up anything helpful. I looked at some of the failing builders, they all fail like this: > for gsl_test in block cblas cdf cheb combination complex const deriv dht diff eigen err fft fit histogram ieee-utils integration interpolation linalg matrix min monte multifit multimin multiroots ntuple ode-initval permutation poly qrng rng roots sort specfunc statistics sum sys vector wavelet; do echo $gsl_test; done \ > | cmp - /home/builder/valgrind-auxtests/gsl-build-g-O3/valgrind-gsl.out || \ > diff -u /home/builder/shared/bb1-2/worker/valgrind-debian-testing-x86_64/build/auxprogs/gsl-1.6.out.x86.exp \ > /home/builder/valgrind-auxtests/gsl-build-g-O3/valgrind-gsl.out > - /home/builder/valgrind-auxtests/gsl-build-g-O3/valgrind-gsl.out differ: char 226, line 32 > --- /home/builder/shared/bb1-2/worker/valgrind-debian-testing-x86_64/build/auxprogs/gsl-1.6.out.x86.exp 2022-08-09 19:45:48.726405142 +0000 > +++ /home/builder/valgrind-auxtests/gsl-build-g-O3/valgrind-gsl.out 2023-04-02 13:43:46.609646296 +0000 > @@ -15,7 +15,6 @@ > histogram > ieee-utils > integration > -FAIL: qawo(f456) elist (7.25063790881233303e-15 observed vs 7.25922435194575979e-15 expected) > interpolation > linalg > matrix > @@ -30,6 +29,10 @@ > poly > qrng > rng > +FAIL: random32-bsd, 10000 steps (852261210 observed vs 1663114331 expected) > +FAIL: random64-bsd, 10000 steps (210970120 observed vs 864469165 expected) > +FAIL: random32-libc5, 10000 steps (367802360 observed vs 1967452027 expected) > +FAIL: random64-libc5, 10000 steps (221021662 observed vs 2106639801 expected) > roots > sort > specfunc > make[1]: Leaving directory '/home/builder/shared/bb1-2/worker/valgrind-debian-testing-x86_64/build/auxprogs' > > I don't know why it's comparing against `gsl-1.6.out.x86.exp` even on x86-64, arm64, ppc64le, and so on. So should we make a new check target that runs a subset of make > regtests? Or maybe have a "ci mode" for regtests? So you would run > CI_MODE=true make regtests and it would skip any vgtest that has > prereq: test -z "$CI_MODE" > > And then add make regtests to the ci and try buildbots? > Seems reasonable. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-03 09:29:43
|
Hi, Cachegrind has an option `--cache-sim`. If you run with `--cache-sim=yes` (the default) it tells it Cachegrind to do a full cache simulation with lots of events: Ir, I1mr, ILmr, Dr, D1mr, DLmr, Dw, D1mw, DLmw. If you run with `--cache-sim=no` then the cache simulation is disabled and you just get one event: Ir. (This is "instruction cache reads", which is equivalent to "instructions executed".) I have been using `--cache-sim=no` almost exclusively for a long time. The cache simulation done by Valgrind is an approximation of the memory hierarchy of a 2002 AMD Athlon processor. Its accuracy for a modern memory hierarchy with three levels of cache, prefetching, non-LRU replacement, and who-knows-what-else is likely to be low. If you want to accurately know about cache behaviour you'd be much better off using hardware counters via `perf` or some other profiler. But `--cache-sim=no` is still very useful because instruction execution counts are still very useful. Therefore, I propose changing the default to `--cache-sim=no`. Does anyone have any objections to this? Thanks. Nick |