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
(5) |
2
(15) |
3
(20) |
|
4
(4) |
5
(11) |
6
(8) |
7
(36) |
8
(23) |
9
(6) |
10
(4) |
|
11
(4) |
12
(19) |
13
(17) |
14
(33) |
15
(16) |
16
(17) |
17
(4) |
|
18
(4) |
19
(30) |
20
(22) |
21
(23) |
22
(29) |
23
(20) |
24
(12) |
|
25
(7) |
26
(33) |
27
(10) |
28
(12) |
29
(19) |
30
(15) |
31
(8) |
|
From: Greg P. <gp...@ap...> - 2009-01-07 22:18:05
|
On Jan 7, 2009, at 1:28 PM, Greg Parker wrote: > On Jan 7, 2009, at 1:24 PM, Greg Parker wrote: >> 3. Makefile.install.am: installing libcoregrind.a and libvex.a. For >> some reason noinst_LIBRARIES is empty here, so I don't know whether >> the expressions work or not. (For whom would libcoregrind.a and >> libvex.a be installed anyway?) > > Never mind, noinst_LIBRARIES is set and #3 is failing, but it's a > syntax error in `expr` not a sed problem. Easy fix: use `expr A : B` instead of `expr match A B`. The latter appears to be a GNU-ism. --- Makefile.install.am (revision 1583) +++ Makefile.install.am (working copy) @@ -33,7 +33,7 @@ fi ; \ if [ -n "$(noinst_LIBRARIES)" ] ; then \ for f in $(noinst_LIBRARIES) expr_wont_match_me; do \ - if expr match $$f libcoregrind_ > /dev/null ; then \ + if expr $$f : libcoregrind_ > /dev/null ; then \ pU=`echo $$f | sed -e 's/libcoregrind_//g' -e 's/\.a//g'` ; \ pD=`echo $$pU | sed -e 's/_/-/g'` ; \ $(INSTALL_DATA) $$f $(DESTDIR)$(valdir)/$$pD/libcoregrind.a ; \ -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Greg P. <gp...@ap...> - 2009-01-07 21:28:51
|
On Jan 7, 2009, at 1:24 PM, Greg Parker wrote: > On Jan 7, 2009, at 12:23 PM, Peter Wemm wrote: >> It breaks on FreeBSD's sed too. Build works, but install (and a few >> other things) fail (including ldscript generation). I'd changed >> configure.in locally to find sed and use $(SED) in the scripts so >> that >> one could specify a path to gnu sed on systems where it isn't the >> default one. > > Outside the tests, I see three ugly-looking uses of sed. > > 1. Makefile.am: generating the valt_load_address ldscript. Darwin > doesn't use ldscripts and doesn't support valt_load_address, so we > don't care. > 2. Makefile.install.am: installing tools with hyphens in the name. > exp- > omega ends up in the right place, so I guess this works fine. > 3. Makefile.install.am: installing libcoregrind.a and libvex.a. For > some reason noinst_LIBRARIES is empty here, so I don't know whether > the expressions work or not. (For whom would libcoregrind.a and > libvex.a be installed anyway?) Never mind, noinst_LIBRARIES is set and #3 is failing, but it's a syntax error in `expr` not a sed problem. -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Greg P. <gp...@ap...> - 2009-01-07 21:24:30
|
On Jan 7, 2009, at 12:23 PM, Peter Wemm wrote: > It breaks on FreeBSD's sed too. Build works, but install (and a few > other things) fail (including ldscript generation). I'd changed > configure.in locally to find sed and use $(SED) in the scripts so that > one could specify a path to gnu sed on systems where it isn't the > default one. Outside the tests, I see three ugly-looking uses of sed. 1. Makefile.am: generating the valt_load_address ldscript. Darwin doesn't use ldscripts and doesn't support valt_load_address, so we don't care. 2. Makefile.install.am: installing tools with hyphens in the name. exp- omega ends up in the right place, so I guess this works fine. 3. Makefile.install.am: installing libcoregrind.a and libvex.a. For some reason noinst_LIBRARIES is empty here, so I don't know whether the expressions work or not. (For whom would libcoregrind.a and libvex.a be installed anyway?) Is there anything else that might require GNU sed? -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Peter W. <pe...@we...> - 2009-01-07 20:23:24
|
On Tue, Jan 6, 2009 at 7:46 PM, Nicholas Nethercote <n.n...@gm...> wrote: > On Wed, Jan 7, 2009 at 2:38 PM, Greg Parker <gp...@ap...> wrote: >> >> Oh, I've already done that; the build seems to work with Darwin sed. But >> it'll need to be cleaned up eventually, and I was hoping whoever had put >> that in still remembered what exactly it was for. > > It was Julian in r8442, he just said: > > * Make sure we're using GNU sed; install can otherwise fail > > Nick It breaks on FreeBSD's sed too. Build works, but install (and a few other things) fail (including ldscript generation). I'd changed configure.in locally to find sed and use $(SED) in the scripts so that one could specify a path to gnu sed on systems where it isn't the default one. -- Peter Wemm - pe...@we...; peter@FreeBSD.org; pe...@ya...; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell |
|
From: Julian S. <js...@ac...> - 2009-01-07 17:29:18
|
> I just found a piece of really simple and sensible looking code that
> produces a false positive:
>
> for( i = 0; i < 12; ++i )
> {
> longmonth[i] = NULL;
> shortmonth[i] = NULL;
> }
I can't reproduce this failure, on openSUSE 11.0 (gcc 4.3.1, 64 bit),
compiled -O1 or -O0:
#include <stdio.h>
void* longmonth[12];
void* shortmonth[12];
int main ( void )
{
long i;
for( i = 0; i < 12; ++i )
{
longmonth[i] = NULL;
shortmonth[i] = NULL;
}
return 0;
}
$ vTRUNK --tool=exp-ptrcheck ./months
[...]
==18554== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> The reason, obviously, is that the compiler has reused the same register
> to hold the base address of both arrays - the compiled body of that loop
> looks like this:
>
> 1388e: 8b 45 f4 mov -0xc(%rbp),%eax
> 13891: 48 98 cltq
> 13893: 48 8d 14 c5 00 00 00 lea 0x0(,%rax,8),%rdx
> 1389a: 00
> 1389b: 48 8d 05 7e 22 22 00 lea 0x22227e(%rip),%rax
> # 235b20 <longmonth>
> 138a2: 48 c7 04 02 00 00 00 movq $0x0,(%rdx,%rax,1)
> 138a9: 00
> 138aa: 8b 45 f4 mov -0xc(%rbp),%eax
> 138ad: 48 98 cltq
> 138af: 48 8d 14 c5 00 00 00 lea 0x0(,%rax,8),%rdx
> 138b6: 00
> 138b7: 48 8d 05 c2 22 22 00 lea 0x2222c2(%rip),%rax
> # 235b80 <shortmonth>
> 138be: 48 c7 04 02 00 00 00 movq $0x0,(%rdx,%rax,1)
What the checking does (for these global arrays) is to watch which
arrays the store instructions write into. It doesn't care what value
is in what register -- that's only of interest for heap-allocated arrays.
What it is trying to establish is that the first store ..
> 138a2: 48 c7 04 02 00 00 00 movq $0x0,(%rdx,%rax,1)
> 138a9: 00
always writes the same array (longmonth, presumably) and that the second
store
> 138be: 48 c7 04 02 00 00 00 movq $0x0,(%rdx,%rax,1)
always writes in the same array (shortmonth, presumably). As per
http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.how-works.sg-checks
> The trouble is that if code as simple as that produces a false positive
> then you have to wonder how much people will be prepared to try and wade
> through the warnings?
Absolutely. But I think there's something else going on here. Could you
send a complete test case, + details of gcc, optimisation level, etc,
you used?
J
|
|
From: Julian S. <js...@ac...> - 2009-01-07 17:11:16
|
On Wednesday 07 January 2009, Bart Van Assche wrote: > On Mon, Dec 22, 2008 at 10:57 PM, Paul Mackerras <pa...@sa...> wrote: > > Another way to find out what the hardware can do is to look at the > > AT_HWCAP and AT_PLATFORM entries in the ELF auxiliary table. > > Thanks a lot for this information. Can anyone tell me whether there is > already support present in Valgrind for accessing the ELF auxiliary > table, or where I should start looking ? At least for fixing http://bugs.kde.org/show_bug.cgi?id=176926, I would prefer to continue using the SIGILL scheme, unless there's a good reason to move the using the ELF auxiliary table. At least superficially, #176926 looks quite simple to fix -- catch SIGFPE as well as SIGILL in the relevant piece of detection code. J |
|
From: Tom H. <to...@co...> - 2009-01-07 15:56:42
|
Julian Seward wrote:
>> Well my experiments with ptrcheck so far have amounted to be managing to
>> run up our software under it and get lots of false positives ;-)
>
> That's not good. Are they all of any particular form? Can you show
> some details?
I just found a piece of really simple and sensible looking code that
produces a false positive:
for( i = 0; i < 12; ++i )
{
longmonth[i] = NULL;
shortmonth[i] = NULL;
}
yields this:
Expected: global array "longmonth" in object with soname "NONE"
Actual: global array "shortmonth" in object with soname "NONE"
The reason, obviously, is that the compiler has reused the same register
to hold the base address of both arrays - the compiled body of that loop
looks like this:
1388e: 8b 45 f4 mov -0xc(%rbp),%eax
13891: 48 98 cltq
13893: 48 8d 14 c5 00 00 00 lea 0x0(,%rax,8),%rdx
1389a: 00
1389b: 48 8d 05 7e 22 22 00 lea 0x22227e(%rip),%rax
# 235b20 <longmonth>
138a2: 48 c7 04 02 00 00 00 movq $0x0,(%rdx,%rax,1)
138a9: 00
138aa: 8b 45 f4 mov -0xc(%rbp),%eax
138ad: 48 98 cltq
138af: 48 8d 14 c5 00 00 00 lea 0x0(,%rax,8),%rdx
138b6: 00
138b7: 48 8d 05 c2 22 22 00 lea 0x2222c2(%rip),%rax
# 235b80 <shortmonth>
138be: 48 c7 04 02 00 00 00 movq $0x0,(%rdx,%rax,1)
So it is using rax for the base and rdx for the index on both
assignments. In fact there is then a second loop over a different array
using i as the index again which produces another warning...
The trouble is that if code as simple as that produces a false positive
then you have to wonder how much people will be prepared to try and wade
through the warnings?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2009-01-07 15:44:23
|
Bart Van Assche wrote: > On Mon, Dec 22, 2008 at 10:57 PM, Paul Mackerras <pa...@sa...> wrote: >> Another way to find out what the hardware can do is to look at the >> AT_HWCAP and AT_PLATFORM entries in the ELF auxiliary table. > > Thanks a lot for this information. Can anyone tell me whether there is > already support present in Valgrind for accessing the ELF auxiliary > table, or where I should start looking ? Well m_main.c has a copy of the auxv in the_iifii.client_auxv once ii_create_image has run. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <to...@co...> - 2009-01-07 15:36:59
|
Julian Seward wrote: >> - Buffers allocated on the stack with alloca() which is something >> that I don't have a good solution for. > > Hmm. I'd have thought that wouldn't be a problem. An access to an > unlabelled section on the stack would be considered "I don't know > what this is". Provided the same instruction continues to access > in an unlabelled section (until the frame exits) there should be no > error reported. An error is only reported for transitions from > known to unknown (or back) and for known-to-different-known areas. > (where "known" means "stack area associated with a known variable"). > > But maybe it's more complex. Any possibility of a simple test case? Attached. >> - Constant strings, which obviously have no variable information >> associated with them in the DWARF so trigger a warning. > > I would have thought these too to be harmless. Hum. This one looks like it must be more complicated then I thought and I'm trying to reproduce it at the moment... Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Bart V. A. <bar...@gm...> - 2009-01-07 15:36:15
|
On Mon, Dec 22, 2008 at 10:57 PM, Paul Mackerras <pa...@sa...> wrote: > Another way to find out what the hardware can do is to look at the > AT_HWCAP and AT_PLATFORM entries in the ELF auxiliary table. Thanks a lot for this information. Can anyone tell me whether there is already support present in Valgrind for accessing the ELF auxiliary table, or where I should start looking ? Bart. |
|
From: Julian S. <js...@ac...> - 2009-01-07 15:27:49
|
> - Buffers allocated on the stack with alloca() which is something > that I don't have a good solution for. Hmm. I'd have thought that wouldn't be a problem. An access to an unlabelled section on the stack would be considered "I don't know what this is". Provided the same instruction continues to access in an unlabelled section (until the frame exits) there should be no error reported. An error is only reported for transitions from known to unknown (or back) and for known-to-different-known areas. (where "known" means "stack area associated with a known variable"). But maybe it's more complex. Any possibility of a simple test case? > - Constant strings, which obviously have no variable information > associated with them in the DWARF so trigger a warning. I would have thought these too to be harmless. Hum. J |
|
From: Tom H. <to...@co...> - 2009-01-07 15:08:42
|
Julian Seward wrote:
>> Well my experiments with ptrcheck so far have amounted to be managing to
>> run up our software under it and get lots of false positives ;-)
>
> That's not good. Are they all of any particular form? Can you show
> some details?
All the ones I've looked at so far, other than one which is just us
doing horrible things that hit the limits on what it can do with stack
variables, fall into two groups:
- Buffers allocated on the stack with alloca() which is something
that I don't have a good solution for.
- Constant strings, which obviously have no variable information
associated with them in the DWARF so trigger a warning.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2009-01-07 15:04:47
|
> Well my experiments with ptrcheck so far have amounted to be managing to > run up our software under it and get lots of false positives ;-) That's not good. Are they all of any particular form? Can you show some details? J |
|
From: Julian S. <js...@ac...> - 2009-01-07 15:01:54
|
> > Yes it does. It never occurred to me before that the segment-vs-section > > mapping stuff needed to be taken into account. > > > > Any chance you can hack up a patch for contemplation? > > Attached... Amazing stuff. Thanks. I'll give it a spin a bit later in the week. I presume if you're trying out ptrcheck then you'll continue to indirectly test this stuff over the next few days anyway. Perhaps it would be wise to put it on a branch for testing/refinement, and if it looks good, merge it? Any thoughts on the best way to stabilise/validate it? I'm keen to merge it in since it's obviously an improvement on what's currently there, but also a bit nervous since it touches lots of stuff, particularly stack unwinding on amd64-linux. IIRC there were various fiddly corner cases in the unwinder which took a long time to stabilise. Perhaps all that fiddlyness (to do with biasing hacks) was merely a side-effect of the central kludge, though, and so is now gone. J |
|
From: Tom H. <to...@co...> - 2009-01-07 12:52:21
|
Julian Seward wrote: > I'll give it a spin a bit later in the week. I presume if you're > trying out ptrcheck then you'll continue to indirectly test this > stuff over the next few days anyway. Well my experiments with ptrcheck so far have amounted to be managing to run up our software under it and get lots of false positives ;-) I will probably play with it a bit more though. > Perhaps it would be wise to put it on a branch for testing/refinement, > and if it looks good, merge it? Any thoughts on the best way to > stabilise/validate it? I'm keen to merge it in since it's obviously > an improvement on what's currently there, but also a bit nervous since > it touches lots of stuff, particularly stack unwinding on amd64-linux. If you like. I've got another almost finished patch here to make it track the rodata section as well which may allow it to pick up a few more things. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: <sv...@va...> - 2009-01-07 09:35:15
|
Author: sewardj
Date: 2009-01-07 09:35:10 +0000 (Wed, 07 Jan 2009)
New Revision: 8917
Log:
Handle __NR_socketpair in Ptrcheck.
Modified:
trunk/exp-ptrcheck/h_main.c
Modified: trunk/exp-ptrcheck/h_main.c
===================================================================
--- trunk/exp-ptrcheck/h_main.c 2009-01-07 08:08:41 UTC (rev 8916)
+++ trunk/exp-ptrcheck/h_main.c 2009-01-07 09:35:10 UTC (rev 8917)
@@ -2338,6 +2338,9 @@
# if defined(__NR_socketcall)
ADD(0, __NR_socketcall); /* the nasty x86-linux socket multiplexor */
# endif
+# if defined(__NR_socketpair)
+ ADD(0, __NR_socketpair);
+# endif
# if defined(__NR_statfs64)
ADD(0, __NR_statfs64);
# endif
|
|
From: <sv...@va...> - 2009-01-07 08:08:50
|
Author: njn
Date: 2009-01-07 08:08:41 +0000 (Wed, 07 Jan 2009)
New Revision: 8916
Log:
trunk/nightly/bin/nightly
Be POSIXy.
Modified:
trunk/nightly/bin/nightly
Modified: trunk/nightly/bin/nightly
===================================================================
--- trunk/nightly/bin/nightly 2009-01-07 06:19:03 UTC (rev 8915)
+++ trunk/nightly/bin/nightly 2009-01-07 08:08:41 UTC (rev 8916)
@@ -177,7 +177,7 @@
if [ `wc -l < $i` -le $MAX_LINES ] ; then
cat $i >> diffs
else
- head -$MAX_LINES $i >> diffs
+ head -n $MAX_LINES $i >> diffs
echo "<truncated beyond $MAX_LINES lines>" >> diffs
fi
done
|
|
From: Bart V. A. <bar...@gm...> - 2009-01-07 07:21:11
|
On Wed, Jan 7, 2009 at 7:19 AM, <sv...@va...> wrote: > Modified: trunk/nightly/bin/nightly ... > + head -$MAX_LINES $i >> diffs The proper POSIX syntax is head -n $MAX_LINES $i -- see also http://www.opengroup.org/onlinepubs/009695399/utilities/head.html. Bart. |
|
From: Bart V. A. <bar...@gm...> - 2009-01-07 07:15:02
|
On Wed, Jan 7, 2009 at 7:23 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On a related topic, the 'nightly' script uses the 'source' command to > source another file. > This is fine on bash, tcsh, csh, zsh. But sh, dash and ksh use '.'. > One possibility is to change the script to use #!/bin/bash instead of > #!/bin/sh -- Bart, would that be ok for your Georgia tech machines > that use tcsh? Or is there another way to do this? My personal preference is to stick to /bin/sh, and to use '.' instead of 'source'. All POSIX systems have /bin/sh, but there is no guarantee that /bin/bash is present. If I remember correctly on Ubuntu systems bash is not in the default install. Same on AIX. And on some Linux systems the bash path is /usr/bin/bash instead of /bin/bash. Bart. |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-07 06:49:52
|
Hi, We have VGP_* symbols which specify the platform, and VGO_* which specifies the OS, but no VGA_* ones for the architecture. I thought we did, but seemingly not. This seems like it would be useful -- eg. in memcheck/tests/ the x86/, amd64/, ppc32/ and ppc64 subdirs are chosen in the Makefile.am based on the VGP_* value, but using the VGA_* value would be better -- with the current approach, if we add an x86/NonLinux platform we'll have to add VGP_X86_NonLinux to the test, whereas if they were VGA_* ones there wouldn't be any problem. Any objections to me adding this? Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-07 06:23:03
|
Hi, I just committed some improvements to the 'nightly' script. All the .diff files are now concatenated into a single file (files longer than 100 lines are truncated). The name of this file is passed to the conf/<tag>.sendmail script as a 3rd argument. Installations of the script don't need to use that 3rd arg, but the obvious thing to do is to attach the file containing the diffs. AFAICT the easiest way to do this is to install 'mutt' and use the -a option to add an attachment. I didn't zip the diffs file, because I think it may usually be small enough to not bother, and not zipping it makes it easier to read. I could have put the diffs in a tar file instead. If anyone has a strong preference for that I could do so. Also, since the diffs file is currently not zipped, it would also be easy to append the diffs to the body of the email and get rid of the 3rd argument. Opinions are welcome on that as well. ---- On a related topic, the 'nightly' script uses the 'source' command to source another file. This is fine on bash, tcsh, csh, zsh. But sh, dash and ksh use '.'. One possibility is to change the script to use #!/bin/bash instead of #!/bin/sh -- Bart, would that be ok for your Georgia tech machines that use tcsh? Or is there another way to do this? Nick |
|
From: <sv...@va...> - 2009-01-07 06:19:08
|
Author: njn
Date: 2009-01-07 06:19:03 +0000 (Wed, 07 Jan 2009)
New Revision: 8915
Log:
Index: nightly/bin/nightly
- Check that it is passed two arguments, abort if not (avoids some
possibly confusing behaviour).
- Remove various uses of $ABT_TOP in paths; it's not necessary because
the first thing the script does is 'cd' to $ABT_TOP. Furthemore, some
paths lacked the $ABT_TOP which was confusing.
- Gather up all the diffs from the tests, grab the first 100 lines (or
less, if shorter) of each, and concatenate into a file, the name of
which is passed to the <tag>.sendmail script so it can be attached.
Index: nightly/README.txt
Explain the new 3rd argument.
Modified:
trunk/nightly/README.txt
trunk/nightly/bin/nightly
Modified: trunk/nightly/README.txt
===================================================================
--- trunk/nightly/README.txt 2009-01-07 04:47:20 UTC (rev 8914)
+++ trunk/nightly/README.txt 2009-01-07 06:19:03 UTC (rev 8915)
@@ -9,7 +9,7 @@
To use, choose a tag, probably a machine name, and run
- bin/nightly /path/to/valgrind/nightly <tag>
+ bin/nightly /path/to/valgrind/nightly/ <tag>
and supply the following two config files:
@@ -29,4 +29,7 @@
- conf/<tag>.sendmail: this should be a script that sends an email to the
desired recipient (eg. the valgrind-developers list). It must take two
command line arguments. The first is the email subject line, the second
- is the email's body.
+ is the name of the file containing the email's body (showing the tests
+ that failed, and the difference between now and 24 hours ago), the third
+ is the name of the file containing all the diffs (which can be made into
+ an attachment, for example).
Modified: trunk/nightly/bin/nightly
===================================================================
--- trunk/nightly/bin/nightly 2009-01-07 04:47:20 UTC (rev 8914)
+++ trunk/nightly/bin/nightly 2009-01-07 06:19:03 UTC (rev 8915)
@@ -39,6 +39,12 @@
#----------------------------------------------------------------------------
# Startup
#----------------------------------------------------------------------------
+# Must have at two arguments
+if [ $# -ne 2 ] ; then
+ echo "usage: bin/night /path/to/valgrind/nightly <tag>"
+ exit 1
+fi
+
# Get args from command line
ABT_TOP=$1
ABT_MACHINE=$2
@@ -51,7 +57,8 @@
cd $ABT_TOP
-source $ABT_TOP/conf/$ABT_MACHINE.conf
+# Setup any relevant environment variables from conf/<tag>.conf.
+source conf/$ABT_MACHINE.conf
if [ "${ABT_JOBS}" = "" ]; then
ABT_JOBS=1
fi
@@ -92,7 +99,7 @@
\
runcmd $logfile \
"Configuring valgrind " \
- "cd valgrind && ./autogen.sh && ./configure --prefix=$ABT_TOP/Inst ${ABT_CONFIGURE_OPTIONS}" && \
+ "cd valgrind && ./autogen.sh && ./configure --prefix=`pwd`/Inst ${ABT_CONFIGURE_OPTIONS}" && \
\
runcmd $logfile \
"Building valgrind " \
@@ -155,7 +162,29 @@
echo >> final
fi
-# Email the results
-$ABT_TOP/conf/$ABT_MACHINE.sendmail \
+# Gather up the diffs (at most the first 100 lines for each one) into a
+# single file.
+MAX_LINES=100
+rm -f diffs
+diff_files=`find . -name '*.diff'`
+if [ z"$diff_files" = z ] ; then
+ echo "Congratulations, all tests passed!" >> diffs
+else
+ for i in $diff_files ; do
+ echo "=================================================" >> diffs
+ echo $i >> diffs
+ echo "=================================================" >> diffs
+ if [ `wc -l < $i` -le $MAX_LINES ] ; then
+ cat $i >> diffs
+ else
+ head -$MAX_LINES $i >> diffs
+ echo "<truncated beyond $MAX_LINES lines>" >> diffs
+ fi
+ done
+fi
+
+# Use the conf/<tag>.sendmail script to email the results.
+conf/$ABT_MACHINE.sendmail \
"$ABT_START nightly build ($ABT_MACHINE, $ABT_DETAILS)" \
- $ABT_TOP/final
+ final \
+ diffs
|
|
From: <sv...@va...> - 2009-01-07 04:47:25
|
Author: njn
Date: 2009-01-07 04:47:20 +0000 (Wed, 07 Jan 2009)
New Revision: 8914
Log:
trunk/nightly/bin/nightly
Use '=' instead of '==', which is a bash-ism that doesn't work on
Debian/Ubuntu systems that have dash installed as /bin/sh. It only
mildly affected the script's running -- it made it say that certain
stages failed when really they didn't.
Modified:
trunk/nightly/bin/nightly
Modified: trunk/nightly/bin/nightly
===================================================================
--- trunk/nightly/bin/nightly 2009-01-07 04:14:42 UTC (rev 8913)
+++ trunk/nightly/bin/nightly 2009-01-07 04:47:20 UTC (rev 8914)
@@ -26,7 +26,7 @@
res=$?
# Write result to the short logfile
- if [ $res == 0 ]
+ if [ $res = 0 ]
then
echo "done" >> $logfile.short
else
|
|
From: <sv...@va...> - 2009-01-07 04:14:59
|
Author: njn
Date: 2009-01-07 04:14:42 +0000 (Wed, 07 Jan 2009)
New Revision: 8913
Log:
Comment-only changes.
trunk/nightly/bin/nightly
trunk/nightly/README.txt
Greatly improved the description of how to use this script; a user now
has a fighting chance of using the script without actually reading it.
trunk/nightly/conf/nemesis.sendmail
trunk/nightly/conf/georgia-tech-cellbuzz.sendmail
Clarified the usage comments.
Modified:
trunk/nightly/README.txt
trunk/nightly/bin/nightly
trunk/nightly/conf/georgia-tech-cellbuzz.sendmail
trunk/nightly/conf/nemesis.sendmail
Modified: trunk/nightly/README.txt
===================================================================
--- trunk/nightly/README.txt 2009-01-07 02:34:06 UTC (rev 8912)
+++ trunk/nightly/README.txt 2009-01-07 04:14:42 UTC (rev 8913)
@@ -9,7 +9,24 @@
To use, choose a tag, probably a machine name, and run
- bin/nightly /path/to/valgrind/nightly tag
+ bin/nightly /path/to/valgrind/nightly <tag>
-and supply conf/tag.conf and conf/tag.sendmail.
+and supply the following two config files:
+- conf/<tag>.conf: this is sourced by the 'nightly' script, and can define
+ any or all of the following environment variables:
+
+ ABT_DETAILS: describes the machine in more detail, eg. the OS. The default
+ is empty.
+ ABT_CONFIGURE_OPTIONS: gives extra configure options. The default is empty.
+ ABT_RUN_REGTEST: if provided, it must be the name of an argumentless shell
+ function (also specified in the tag.conf file) it's an argumentless bash
+ function that will be used to run the tests. If not specified, the usual
+ "perl tests/vg_regtest --all" will be used.
+ ABT_JOBS: allows parallel builds -- it's passed as the argument to "make
+ -j" when building Valgrind and the tests. The default is 1.
+
+- conf/<tag>.sendmail: this should be a script that sends an email to the
+ desired recipient (eg. the valgrind-developers list). It must take two
+ command line arguments. The first is the email subject line, the second
+ is the email's body.
Modified: trunk/nightly/bin/nightly
===================================================================
--- trunk/nightly/bin/nightly 2009-01-07 02:34:06 UTC (rev 8912)
+++ trunk/nightly/bin/nightly 2009-01-07 04:14:42 UTC (rev 8913)
@@ -2,10 +2,7 @@
#----------------------------------------------------------------------------
# Automated build and test for Valgrind. Compares Valgrind from 24 hours
-# ago with the current one.
-#
-# Use: two args, first is path to top of ValgrindABT tree
-# second is name of machine
+# ago with the current one. See the README.txt on how to run it.
#----------------------------------------------------------------------------
#----------------------------------------------------------------------------
Modified: trunk/nightly/conf/georgia-tech-cellbuzz.sendmail
===================================================================
--- trunk/nightly/conf/georgia-tech-cellbuzz.sendmail 2009-01-07 02:34:06 UTC (rev 8912)
+++ trunk/nightly/conf/georgia-tech-cellbuzz.sendmail 2009-01-07 04:14:42 UTC (rev 8913)
@@ -1,4 +1,4 @@
-#use: subject file-to-mail
+# use: georgia-tech-cellbuzz.sendmail subject file-to-mail
/bin/mailx -s "$1" val...@li... -- -R bar...@gm... -r bar...@gm... < $2
Modified: trunk/nightly/conf/nemesis.sendmail
===================================================================
--- trunk/nightly/conf/nemesis.sendmail 2009-01-07 02:34:06 UTC (rev 8912)
+++ trunk/nightly/conf/nemesis.sendmail 2009-01-07 04:14:42 UTC (rev 8913)
@@ -1,5 +1,5 @@
-#use: subject file-to-mail
+# use: nemesis.sendmail subject file-to-mail
/usr/bin/mail -s "$1" -R js...@ac... -r js...@ac... val...@li... < $2
-
\ No newline at end of file
+
|
|
From: Tom H. <th...@cy...> - 2009-01-07 04:06:24
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-01-07 03:05:06 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 472 tests, 8 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) |