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-01 22:56:07
|
Hi Nick, On Sat, Mar 25, 2023 at 11:23:54AM +1100, Nicholas Nethercote wrote: > One way to do it is to divide the tests into "must pass on CI" and "the > rest". I suspect there are plenty of tests that work on all platforms, > which would give a lot of useful coverage from the start. Over time you can > hopefully move tests from the first category to the second. 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. > The other way to do it is to divide the tests into "run on CI" and "don't > run on CI", i.e. exceptions, which does require a mechanism for specifying > those exceptions. In practice I think this works out much the same as the > first approach, because a test that consistently fails on one platform > isn't much use. (In fact, it can have negative value if its presence masks > new failures in other tests.) 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? Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2023-04-01 22:04:26
|
Hi, On Sat, Mar 25, 2023 at 11:25:12AM +1100, Nicholas Nethercote wrote: > On Fri, 24 Mar 2023 at 22:25, Mark Wielaard <ma...@kl...> wrote: > > We aren't (yet?) using all of them (and some of them would mean moving > > over bugzilla and the mailinglist, which might be controversial). But > > I'll at least add the buildbot CI testers to the website (and we should > > at least make use of the try-branches) this weekend. > > Great! I'd be happy to try this out. Though I guess I'd need to do a > no-change try run before testing a real change, to give a baseline of > expected test failures, right? I setup the user try branches on sourceware (just for the setups that have passing aux-tests) debian-arm64, debian-armhf, debian-i386, debian-ppc64, fedora-ppc64le, fedora-s390x, ibm-power9, opensuseleap-x86_64. And added instructions on how to use them into README_DEVELOPERS: Every developer with commit access can use try branches. Code committed 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: git checkout -b frob ...hack, hack, hack... OK, looks good to submit git commit -a -m "Awesome hack" git push origin frob:users/username/try-frob 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 references to all the logs. You can also find the logs and the builds here: https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try Afterwards you can delete the branch again: git push origin :users/username/try-frob |
|
From: Mark W. <ma...@so...> - 2023-04-01 21:58:43
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=03e36bc36ec9fe9a6ea83e3ad0338480a5a97f6c commit 03e36bc36ec9fe9a6ea83e3ad0338480a5a97f6c Author: Mark Wielaard <ma...@kl...> Date: Sat Apr 1 23:58:14 2023 +0200 Commit access and try branches Diff: --- README_DEVELOPERS | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/README_DEVELOPERS b/README_DEVELOPERS index 5b0a1bc6ad..4ed21a561b 100644 --- a/README_DEVELOPERS +++ b/README_DEVELOPERS @@ -80,6 +80,33 @@ compare them on all the performance tests: perl perf/vg_perf --vg=../trunk1 --vg=../trunk2 perf/ +Commit access and try branches +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +To get commit access to the valgrind git repository on sourceware +you will have to ask an existing developer and fill in the following +form: https://sourceware.org/cgi-bin/pdw/ps_form.cgi + +Every developer with commit access can use try branches. Code committed +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: + + git checkout -b frob + ...hack, hack, hack... OK, looks good to submit + git commit -a -m "Awesome hack" + git push origin frob:users/username/try-frob + +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 +references to all the logs. You can also find the logs and the builds here: +https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try + +Afterwards you can delete the branch again: + + git push origin :users/username/try-frob + Debugging Valgrind with GDB ~~~~~~~~~~~~~~~~~~~~~~~~~~~ To debug the valgrind launcher program (<prefix>/bin/valgrind) just |
|
From: Paul F. <pa...@so...> - 2023-04-01 20:29:48
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=3f4052623c6246ee0d59db00d607ec858cefa849 commit 3f4052623c6246ee0d59db00d607ec858cefa849 Author: Paul Floyd <pj...@wa...> Date: Sat Apr 1 22:28:36 2023 +0200 Darwin: try to improve posix_memalign / zone_memalign wrapper It still doesn't set errno though. Diff: --- coregrind/m_replacemalloc/vg_replace_malloc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/coregrind/m_replacemalloc/vg_replace_malloc.c b/coregrind/m_replacemalloc/vg_replace_malloc.c index db2fc5f309..5977fa317b 100644 --- a/coregrind/m_replacemalloc/vg_replace_malloc.c +++ b/coregrind/m_replacemalloc/vg_replace_malloc.c @@ -1575,7 +1575,8 @@ extern int *___errno (void) __attribute__((weak)); * */ - /* @todo PJF exactly what is the behaviour if this? */ + /* Probably in the wrong place, this is the function + called by posix_memalign, at least on macOS 10.13 */ #define ZONEMEMALIGN(soname, fnname) \ \ void* VG_REPLACE_FUNCTION_EZU(10100,soname,fnname) \ @@ -1591,6 +1592,12 @@ extern int *___errno (void) __attribute__((weak)); MALLOC_TRACE("zone_memalign(%p, al %llu, size %llu)", \ zone, (ULong)alignment, (ULong)n ); \ \ + if (alignment == 0 \ + || alignment % sizeof (void *) != 0 \ + || (alignment & (alignment - 1)) != 0) { \ + SET_ERRNO_EINVAL; \ + return NULL; \ + } \ /* Round up to minimum alignment if necessary. */ \ if (alignment < VG_MIN_MALLOC_SZB) \ alignment = VG_MIN_MALLOC_SZB; \ |
|
From: Paul F. <pa...@so...> - 2023-04-01 19:13:43
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=e105ce0d8f69f3784168562823ec9111e92aea95 commit e105ce0d8f69f3784168562823ec9111e92aea95 Author: Paul Floyd <pj...@wa...> Date: Sat Apr 1 21:11:58 2023 +0200 Darwin regtest: another test using aligned_alloc I added this test because I wanted to check the behaviour of aligned_alloc on current macOS, but Valgrind doesn't support it yet. Diff: --- memcheck/tests/darwin/aligned_alloc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/memcheck/tests/darwin/aligned_alloc.c b/memcheck/tests/darwin/aligned_alloc.c index 1c2fdb78cb..bcbae51fe4 100644 --- a/memcheck/tests/darwin/aligned_alloc.c +++ b/memcheck/tests/darwin/aligned_alloc.c @@ -1,8 +1,11 @@ #include <stdlib.h> #include <assert.h> +#include "../../../config.h" int main(void) { + // @todo PJF this is a placeholder for 10.15 and later support +#if !defined(VGO_darwin) char* p = NULL; // zero size @@ -14,6 +17,7 @@ int main(void) // align not power of 2 p = aligned_alloc(40, 160); assert(p == NULL); +#endif // @todo PJF this works standalone // but for some reason it doesn't fail in arena_memalign |
|
From: Paul F. <pa...@so...> - 2023-04-01 18:57:10
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=abf513febd1f98aad37201fe91468bf94ebae7f8 commit abf513febd1f98aad37201fe91468bf94ebae7f8 Author: Paul Floyd <pj...@wa...> Date: Sat Apr 1 20:55:22 2023 +0200 Darwin regtest: fix building on older OS versions aligned_alloc was added to macOS 10.15 and 10.13 is the latest that we support. Diff: --- memcheck/tests/memalign_args.c | 2 ++ memcheck/tests/memalign_args.stderr.exp | 4 ++-- memcheck/tests/memalign_args.stderr.exp-glibc | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/memcheck/tests/memalign_args.c b/memcheck/tests/memalign_args.c index 0946a6ce98..9c774d61ee 100644 --- a/memcheck/tests/memalign_args.c +++ b/memcheck/tests/memalign_args.c @@ -23,8 +23,10 @@ int main(void) res = posix_memalign((void **)&mem,align,size); free(mem); +#if !defined(VGO_darwin) p = aligned_alloc(align, size); free(p); +#endif p = valloc(size); free(p); diff --git a/memcheck/tests/memalign_args.stderr.exp b/memcheck/tests/memalign_args.stderr.exp index 4d426d3696..5482798875 100644 --- a/memcheck/tests/memalign_args.stderr.exp +++ b/memcheck/tests/memalign_args.stderr.exp @@ -8,8 +8,8 @@ Conditional jump or move depends on uninitialised value(s) Conditional jump or move depends on uninitialised value(s) at 0x........: aligned_alloc (vg_replace_malloc.c:...) - by 0x........: main (memalign_args.c:26) + by 0x........: main (memalign_args.c:27) Conditional jump or move depends on uninitialised value(s) at 0x........: valloc (vg_replace_malloc.c:...) - by 0x........: main (memalign_args.c:29) + by 0x........: main (memalign_args.c:31) diff --git a/memcheck/tests/memalign_args.stderr.exp-glibc b/memcheck/tests/memalign_args.stderr.exp-glibc index 8106196391..30cc1dc923 100644 --- a/memcheck/tests/memalign_args.stderr.exp-glibc +++ b/memcheck/tests/memalign_args.stderr.exp-glibc @@ -8,8 +8,8 @@ Conditional jump or move depends on uninitialised value(s) Conditional jump or move depends on uninitialised value(s) at 0x........: memalign (vg_replace_malloc.c:...) - by 0x........: main (memalign_args.c:26) + by 0x........: main (memalign_args.c:27) Conditional jump or move depends on uninitialised value(s) at 0x........: valloc (vg_replace_malloc.c:...) - by 0x........: main (memalign_args.c:29) + by 0x........: main (memalign_args.c:31) |