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
(15) |
2
(12) |
3
(11) |
4
(20) |
5
(6) |
|
6
(6) |
7
(7) |
8
(8) |
9
(17) |
10
(25) |
11
(27) |
12
(6) |
|
13
(28) |
14
(16) |
15
(20) |
16
(9) |
17
(26) |
18
(7) |
19
(25) |
|
20
(7) |
21
(18) |
22
(25) |
23
(15) |
24
(21) |
25
(32) |
26
(15) |
|
27
(23) |
28
(33) |
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2005-02-11 23:09:26
|
On Fri, 2005-02-11 at 15:13 -0600, Nicholas Nethercote wrote: > On Fri, 11 Feb 2005, Julian Seward wrote: > > > It's dubious that the profiling can be made to work portably/reliably > > now, and in any case since the JIT has been sawn off and made into a > > library, profiling at least that part of the system is easy anyway > > (by using a standalone test driver). So we may as well forget about > > it, and nuke the associated code. > > It would be nice to have some kind of system-wide profiling, though. oprofile is getting very useful for this kind of thing. New versions can now take snapshots of the stack when they sample, so you get more than a simple flat profile. If we can get it to generate some useful profile data for generated code, it should cover almost all of our profiling requirements... J |
|
From: Jeremy F. <je...@go...> - 2005-02-11 23:06:16
|
On Fri, 2005-02-11 at 18:50 +0000, Julian Seward wrote: > > I'd go for --command-line-only=yes, > > I like that one. > > Uh ... what happens if this flag appears only in a .valgrindrc > or $VALGRIND_OPTS :-? I guess the sensible thing to do is say > that it cannot legitimately appear in either of those places. That's an interesting question. By the time the args are parsed, you don't know where they came from because they've all been mushed together into one unified argv by get_command_line(). You'd need to pre-parse the real command-line to avoid fetching any other CLO sources. J |
|
From: Nicholas N. <nj...@cs...> - 2005-02-11 21:14:05
|
On Fri, 11 Feb 2005, Julian Seward wrote: > It's dubious that the profiling can be made to work portably/reliably > now, and in any case since the JIT has been sawn off and made into a > library, profiling at least that part of the system is easy anyway > (by using a standalone test driver). So we may as well forget about > it, and nuke the associated code. It would be nice to have some kind of system-wide profiling, though. N |
|
From: Nicholas N. <nj...@cs...> - 2005-02-11 19:54:42
|
On Fri, 11 Feb 2005, Jeremy Fitzhardinge wrote: >> I don't like the idea of --ignore-config. > > The trouble is that V can pick up command-line options from a variety of > places, but we want the V running in the test harness to be running with > a very specific set of options. I normally run with a ~/.valgrindrc > containing a few of my preferred defaults; it doesn't seem like a good > idea for the regtest valgrind to use them though. --ignore-config would > basically suppress all of V's use of env variables or files for options, > and only use the options explicitly on the command line. Yes, I see that. I just don't want to add another CLO for a problem that could be solved by not using a CLO -- ie. if we explicitly put more CLOs in vg_regtest (CLOs on the command line always override those in .valgrindrc and VALGRIND_OPTS). But I may be swimming against the tide, here. N |
|
From: Julian S. <js...@ac...> - 2005-02-11 18:50:55
|
> I'd go for --command-line-only=yes, I like that one. Uh ... what happens if this flag appears only in a .valgrindrc or $VALGRIND_OPTS :-? I guess the sensible thing to do is say that it cannot legitimately appear in either of those places. J |
|
From: Ashley P. <as...@pi...> - 2005-02-11 18:49:50
|
On 11 Feb 2005, at 12:10, Tom Hughes wrote: > He also suggested > adding a --ignore-configfiles=yes switch to ignore .valgrindrc which > can also cause problems with the tests. Perhaps having a --rf-file=<filename> with filename defaulting to "~/.valgrindrc" would be better, this way the tests can just point it at a empty file. This would avoid the vast majority of the differing codepath issue and might be useful in the field too. Just my 0.02p Ashley, |
|
From: Jeremy F. <je...@go...> - 2005-02-11 18:41:44
|
On Fri, 2005-02-11 at 17:19 +0000, Julian Seward wrote: > Hmm, yes, fair enough. Perhaps it is a good idea. > > I think the meaning isn't too clear from the flag name, tho. > "config" is too vague a term. > > I was thinking --ignore-valgrindrc > but then that doesn't make it clear that $VALGRIND_OPTS is > also ignored. > > Hmm. How about --cmd-line-opts-only ? I'd go for --command-line-only=yes, or maybe --option-search=no. I'd prefer to avoid a CLO with a negative in it. It doesn't matter if its long, because it won't be used too much (in the regtest, and maybe other places where V is invoked by some other tool). J |
|
From: Julian S. <js...@ac...> - 2005-02-11 17:24:40
|
> Any better suggestions for a name? --regression-test-mode ? --maintainer-mode ? J |
|
From: Julian S. <js...@ac...> - 2005-02-11 17:19:24
|
> The trouble is that V can pick up command-line options from a variety of > places, but we want the V running in the test harness to be running with > a very specific set of options. I normally run with a ~/.valgrindrc > containing a few of my preferred defaults; it doesn't seem like a good > idea for the regtest valgrind to use them though. --ignore-config would > basically suppress all of V's use of env variables or files for options, > and only use the options explicitly on the command line. Hmm, yes, fair enough. Perhaps it is a good idea. I think the meaning isn't too clear from the flag name, tho. "config" is too vague a term. I was thinking --ignore-valgrindrc but then that doesn't make it clear that $VALGRIND_OPTS is also ignored. Hmm. How about --cmd-line-opts-only ? Hmm. Cumbersome. Any better suggestions for a name? J |
|
From: Jeremy F. <je...@go...> - 2005-02-11 17:09:04
|
On Fri, 2005-02-11 at 15:51 +0000, Julian Seward wrote: > I don't like the idea of --ignore-config. The trouble is that V can pick up command-line options from a variety of places, but we want the V running in the test harness to be running with a very specific set of options. I normally run with a ~/.valgrindrc containing a few of my preferred defaults; it doesn't seem like a good idea for the regtest valgrind to use them though. --ignore-config would basically suppress all of V's use of env variables or files for options, and only use the options explicitly on the command line. J |
|
From: Julian S. <js...@ac...> - 2005-02-11 15:59:20
|
> I was thinking of having three prefixes. I started with VGA for the > arch-abstraction, which I was doing first. I was going to use VGO and VGP > for OS- and platform-abstraction, but VGP was already taken for > profiling-related stuff, so I ended up just using VGA throughout. > > I'd recommend no longer using VGP for the profiling stuff, since it > doesn't seem worth distinguishing, and using VGA, VGO and VGP as I > originally intended -- those three layers do seem worth distinguishing. I agree. That sounds good to me. It's dubious that the profiling can be made to work portably/reliably now, and in any case since the JIT has been sawn off and made into a library, profiling at least that part of the system is easy anyway (by using a standalone test driver). So we may as well forget about it, and nuke the associated code. In similar vein there's been a lot of rationalising of type names in the vex tree, to get stuff 64-bit clean, and there's more to come. > But I'd say there's no rush; this might be better done once Julian's Vex > tree is merged with CVS. Yes; indeed being too eager about it may even end up making your life more difficult. J |
|
From: Julian S. <js...@ac...> - 2005-02-11 15:52:02
|
> > If people do think it's a good idea then I'll have a look at putting > > it in. The other question is whether to have separate switches or a > > single switch to enable "test mode" or something. > > The tests are too brittle now; making them more robust (but no less > rigourous) would be great. But I'm uneasy about this suggestion. > > Stack traces are tricky. [...] I agree with Nick's analysis ... perhaps more effective filtering of stack traces is in order. --ignore-debuginfo sounds like it might be useful anyway, but I don't like the idea of --ignore-config. I do think it's best if we can fix the regtest system to be more robust without either of these. J |
|
From: Nicholas N. <nj...@cs...> - 2005-02-11 15:01:00
|
On Fri, 11 Feb 2005, Tom Hughes wrote: > This is a typical failure: > > ! at 0x........: accept (in /...libc...) > --- 5 ---- > ! at 0x........: accept (socket.S:63) > > The current stripping strips "/.*libc.*" to "...libc..." which is > fine if there is no debug information available. > > If debug information is available then you just get the name of > the source file and the line number, and there is no sane way to > know that socket.S is part of glibc and strip it to "...libc..." so > that it matches. > > I guess that one option for many tests would be to discard the > location completely and just keep the function name? Hmm, but when the line number is from our test program, we definitely want to keep that. Maybe parameterise the filters: pass them the names of any files that should not stripped from the trace, and strip all others? N |
|
From: Tom H. <to...@co...> - 2005-02-11 14:55:23
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> Stack traces are tricky. We shouldn't just ignore them, because
> they're an important part of the test -- we want them to fail if they
> eg. don't get the line number right. Basically, we want a certain
> level of fuzziness in the stack trace comparison, probably more than
> we have now. I would suggest reworking the filter_stderr_basic script
> to strip out more of the unimportant info from traces. But first, we
> should look at representative examples of test failures caused by
> insufficient fuzziness, so we can see exactly what we should strip
> out. Can Tom or Jeremy provide these?
This is a typical failure:
! at 0x........: accept (in /...libc...)
--- 5 ----
! at 0x........: accept (socket.S:63)
The current stripping strips "/.*libc.*" to "...libc..." which is
fine if there is no debug information available.
If debug information is available then you just get the name of
the source file and the line number, and there is no sane way to
know that socket.S is part of glibc and strip it to "...libc..." so
that it matches.
I guess that one option for many tests would be to discard the
location completely and just keep the function name?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-11 14:54:45
|
On Thu, 10 Feb 2005, Tom Hughes wrote: >>> What's VGOS_() about? Your patch doesn't seem to define it. >>> >>> I assume it is for OS specific code, which is what VGA_() is for. Such >>> code should also go in the appropriate directory (coregrind/linux for >>> linux code). >> >> Yes, it is for OS-specific code. I was using different prefixes for >> OS-specific vs. CPU-specific vs. both. VGA_() isn't used much yet, >> so using VGOS_() for OS and VGA_() for CPU architecture seems like >> a good solution. However, it's still early to worry about that now, >> so either VG_() or VGA_() is fine for this code. > > I noticed after I wrote the previous email that VGA_() seems to be > used for both OS specific, arch specific and OS+arch specific routines > and in fact isn't even used consistently then. I guess that's a result > of it being new. > > We probably need to decide what the rule should be for new work > though - what was your intention what you starting splitting stuff > up Nick? I was thinking of having three prefixes. I started with VGA for the arch-abstraction, which I was doing first. I was going to use VGO and VGP for OS- and platform-abstraction, but VGP was already taken for profiling-related stuff, so I ended up just using VGA throughout. I'd recommend no longer using VGP for the profiling stuff, since it doesn't seem worth distinguishing, and using VGA, VGO and VGP as I originally intended -- those three layers do seem worth distinguishing. (I used eg. "ARCH_" and "PLATFORM_" in some of the macros... perhaps they could be changed to "VGA_" and "VGP_", which are shorter and would then be more consistent. But I'd say there's no rush; this might be better done once Julian's Vex tree is merged with CVS. N |
|
From: Nicholas N. <nj...@cs...> - 2005-02-11 14:49:36
|
On Fri, 11 Feb 2005, Tom Hughes wrote: > Some of the boxes that I run the tests on every night have the > debuginfo packages for glibc installed which means that some tests > fail because they produce output that names source files in the stack > trace instead of just libc-x.x.x.so or whatever. > > I was discussing this with Jeremy the other and he suggested adding > a --ignore-debuginfo=yes switch that the test suite could use to stop > valgrind looking at separated debug information. He also suggested > adding a --ignore-configfiles=yes switch to ignore .valgrindrc which > can also cause problems with the tests. > > What do people think? In one way these sound like good suggestions > and they would resolve real problems with the test suite, but I'm > always wary of anything which means that the tests use a different > code path to normal use... > > If people do think it's a good idea then I'll have a look at putting > it in. The other question is whether to have separate switches or a > single switch to enable "test mode" or something. The tests are too brittle now; making them more robust (but no less rigourous) would be great. But I'm uneasy about this suggestion. Stack traces are tricky. We shouldn't just ignore them, because they're an important part of the test -- we want them to fail if they eg. don't get the line number right. Basically, we want a certain level of fuzziness in the stack trace comparison, probably more than we have now. I would suggest reworking the filter_stderr_basic script to strip out more of the unimportant info from traces. But first, we should look at representative examples of test failures caused by insufficient fuzziness, so we can see exactly what we should strip out. Can Tom or Jeremy provide these? For the --ignore-config suggestion, it might be better to be more explicit about which options are used in the vg_regtest file. N |
|
From: Tom H. <to...@co...> - 2005-02-11 12:10:55
|
Some of the boxes that I run the tests on every night have the debuginfo packages for glibc installed which means that some tests fail because they produce output that names source files in the stack trace instead of just libc-x.x.x.so or whatever. I was discussing this with Jeremy the other and he suggested adding a --ignore-debuginfo=yes switch that the test suite could use to stop valgrind looking at separated debug information. He also suggested adding a --ignore-configfiles=yes switch to ignore .valgrindrc which can also cause problems with the tests. What do people think? In one way these sound like good suggestions and they would resolve real problems with the test suite, but I'm always wary of anything which means that the tests use a different code path to normal use... If people do think it's a good idea then I'll have a look at putting it in. The other question is whether to have separate switches or a single switch to enable "test mode" or something. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <th...@cy...> - 2005-02-11 09:51:02
|
CVS commit by thughes:
Strip the libc path as not all systems use the same version of libc.
M +2 -2 async-sigs.stderr.exp 1.3
M +4 -1 filter_stderr 1.7
--- valgrind/none/tests/async-sigs.stderr.exp #1.2:1.3
@@ -14,5 +14,5 @@
Process terminating with default action of signal 7 (SIGBUS)
- at 0x........: pause (in /lib/tls/libc-2.3.3.so)
+ at 0x........: pause (in /...libc...)
by 0x........: main (async-sigs.c:117)
@@ -20,5 +20,5 @@
Process terminating with default action of signal 7 (SIGBUS)
- at 0x........: pause (in /lib/tls/libc-2.3.3.so)
+ at 0x........: pause (in /...libc...)
by 0x........: main (async-sigs.c:117)
--- valgrind/none/tests/filter_stderr #1.6:1.7
@@ -6,3 +6,6 @@
# Anonymise addresses
-$dir/../../tests/filter_addresses
+$dir/../../tests/filter_addresses |
+
+# Anonymise paths like "(in /foo/bar/libc-baz.so)"
+sed "s/(in \/.*libc.*)$/(in \/...libc...)/"
|
|
From: Jeremy F. <je...@go...> - 2005-02-11 08:45:47
|
On Fri, 2005-02-11 at 02:20 -0500, Greg Parker wrote: > That sounds reasonable. Is the recent libpthread removal mostly > working? I want to start from a base that includes that, but my > changes will involve lots of code motion between files so running > `cvs update` won't be practical for long. If the libpthread changes > mostly work now, then I'll just grab a version now and ignore > further changes to top-of-tree. CVS HEAD is looking pretty solid. I'm working on restoring the lost pthread checking, but that should be pretty localized. Once that's in, it will be released as 2.4. J |
|
From: Greg P. <gp...@us...> - 2005-02-11 07:20:18
|
Julian Seward writes: > The rate of change of the code base is high at the moment, > with some virtual-CPU hacking and other restructuring going > on. Much of this isn't publically visible but will be soon. > > The upshot is that this isn't really a good time for us > to merge in MacOSX changes. We are already wrestling with the > problem of merging two lines of development so as to get amd64 > support working right, and having a third line complicates it > even more. That sounds reasonable. Is the recent libpthread removal mostly working? I want to start from a base that includes that, but my changes will involve lots of code motion between files so running `cvs update` won't be practical for long. If the libpthread changes mostly work now, then I'll just grab a version now and ignore further changes to top-of-tree. And of course the new virtual CPU and IR had better live up to the hype :-) -- Greg Parker gp...@us... |
|
From: <js...@ac...> - 2005-02-11 04:00:39
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-02-11 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 196 tests, 12 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) none/tests/async-sigs (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-02-11 03:27:00
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-02-11 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow pushpopseg: valgrind --num-callers=4 ./pushpopseg rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 203 tests, 10 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/async-sigs (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-11 03:24:07
|
Nightly build on audi ( Red Hat 9 ) started at 2005-02-11 03:15:07 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/async-sigs (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-11 03:18:17
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-02-11 03:10:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow pushpopseg: valgrind --num-callers=4 ./pushpopseg rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 10 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) none/tests/async-sigs (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-11 03:15:40
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-02-11 03:00:05 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 11 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/async-sigs (stderr) make: *** [regtest] Error 1 |