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
(8) |
2
(8) |
3
(7) |
|
4
(3) |
5
(6) |
6
(9) |
7
(8) |
8
(7) |
9
(7) |
10
(18) |
|
11
(7) |
12
(11) |
13
(24) |
14
(13) |
15
(11) |
16
(18) |
17
(7) |
|
18
(8) |
19
(7) |
20
(9) |
21
(24) |
22
(18) |
23
(10) |
24
(7) |
|
25
(8) |
26
(11) |
27
(14) |
28
(7) |
29
(10) |
30
(7) |
|
|
From: Bryan O'S. <bo...@se...> - 2004-04-21 17:51:27
|
On Wed, 2004-04-21 at 10:30, Tom Hughes wrote: > What is libltdl anyway? Part of the evil libtool empire, the conspiracy to drown everything in endless layers of bewildering complexity. Ahem. It's a somewhat portable wrapper around dlopen, dlsym and friends. Pretty much the most inoffensive part of all of the automake/libtool gunk. <b |
|
From: Tom H. <th...@cy...> - 2004-04-21 17:35:05
|
In message <940...@lo...>
Tom Hughes <th...@cy...> wrote:
> In message <200...@co...>
> Tilman Sauerbeck <ti...@co...> wrote:
>
> > since I didn't receive any feedback on my bug report
> > (http://bugs.kde.org/show_bug.cgi?id=78934) yet, I wondered whether
> > I forgot to provide any information about my system or anything that
> > you might need to investigate the issue?
>
> I suspect it's just that nobody's had time to look at it yet. It's
> non-trivial to look at because of the need to obtain the special
> library to get things going. What is libltdl anyway?
Hmm. It seems I already have a libltdl and it's part of libtool... I'd
just never heard of it ;=)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-04-21 17:30:11
|
In message <200...@co...>
Tilman Sauerbeck <ti...@co...> wrote:
> since I didn't receive any feedback on my bug report
> (http://bugs.kde.org/show_bug.cgi?id=78934) yet, I wondered whether
> I forgot to provide any information about my system or anything that
> you might need to investigate the issue?
I suspect it's just that nobody's had time to look at it yet. It's
non-trivial to look at because of the need to obtain the special
library to get things going. What is libltdl anyway?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tilman S. <ti...@co...> - 2004-04-21 17:21:21
|
Hi, since I didn't receive any feedback on my bug report (http://bugs.kde.org/show_bug.cgi?id=78934) yet, I wondered whether I forgot to provide any information about my system or anything that you might need to investigate the issue? -- Regards, Tilman |
|
From: Robert W. <rj...@du...> - 2004-04-21 16:47:59
|
> I've started looking at getting Valgrind running on AMD64 machines, > since my main desktop is now an Athlon64 box. The first thing that > seemed useful was to get Valgrind running with 32-bit executables on > AMD64 machines. I've put a one-line patch on my web site that does > this. It might have helped if I'd included the URL: http://www.durables.org/software/valgrind/ Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@ca...> - 2004-04-21 16:41:41
|
On Wed, 21 Apr 2004, Tom Hughes wrote: > > Hmm; we have an unsatisfactory situation at the moment... #including new > > headers for IOCTLs is a bit dangerous, because some of these headers > > aren't universal. This has prevented us from applying a bunch of IOCTLs > > like this previously. At least, that's my understanding of it. > > So should configure be made to probe for the header then, and only > include that code if it exists? I guess; nobody's ever looked at it thoroughly, AFAIK. > Presumably a system without the header wouldn't suport the ioctl anyway? Yes; the problem is compilation errors. N |
|
From: Tom H. <th...@cy...> - 2004-04-21 16:27:44
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 21 Apr 2004, Tom Hughes wrote:
>
> > Add support for the FBIOGET_VSCREENINFO and FBIOGET_FSCREENINFO ioctls
> > based on a patch from Paul Olav Tvete <pa...@tr...>.
>
> Hmm; we have an unsatisfactory situation at the moment... #including new
> headers for IOCTLs is a bit dangerous, because some of these headers
> aren't universal. This has prevented us from applying a bunch of IOCTLs
> like this previously. At least, that's my understanding of it.
So should configure be made to probe for the header then, and only
include that code if it exists? Presumably a system without the header
wouldn't suport the ioctl anyway?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-21 15:59:42
|
On Wed, 21 Apr 2004, Tom Hughes wrote: > Add support for the FBIOGET_VSCREENINFO and FBIOGET_FSCREENINFO ioctls > based on a patch from Paul Olav Tvete <pa...@tr...>. Hmm; we have an unsatisfactory situation at the moment... #including new headers for IOCTLs is a bit dangerous, because some of these headers aren't universal. This has prevented us from applying a bunch of IOCTLs like this previously. At least, that's my understanding of it. N |
|
From: Tom H. <th...@cy...> - 2004-04-21 15:52:46
|
CVS commit by thughes:
Add support for the FBIOGET_VSCREENINFO and FBIOGET_FSCREENINFO ioctls
based on a patch from Paul Olav Tvete <pa...@tr...>.
CCMAIL: 770...@bu...
M +20 -0 vg_syscalls.c 1.94
M +1 -0 vg_unsafe.h 1.26
--- valgrind/coregrind/vg_syscalls.c #1.93:1.94
@@ -3232,4 +3232,15 @@ PRE(ioctl)
break;
+ case FBIOGET_VSCREENINFO: /* 0x4600 */
+ SYSCALL_TRACK( pre_mem_write,tid,
+ "ioctl(FBIOGET_VSCREENINFO)", arg3,
+ sizeof(struct fb_var_screeninfo));
+ break;
+ case FBIOGET_FSCREENINFO: /* 0x4602 */
+ SYSCALL_TRACK( pre_mem_write,tid,
+ "ioctl(FBIOGET_FSCREENINFO)", arg3,
+ sizeof(struct fb_fix_screeninfo));
+ break;
+
/* We don't have any specific information on it, so
try to do something reasonable based on direction and
@@ -3585,4 +3596,13 @@ POST(ioctl)
break;
+ case FBIOGET_VSCREENINFO: //0x4600
+ if (res == 0)
+ VG_TRACK( post_mem_write,arg3, sizeof(struct fb_var_screeninfo));
+ break;
+ case FBIOGET_FSCREENINFO: //0x4602
+ if (res == 0)
+ VG_TRACK( post_mem_write,arg3, sizeof(struct fb_fix_screeninfo));
+ break;
+
/* We don't have any specific information on it, so
try to do something reasonable based on direction and
--- valgrind/coregrind/vg_unsafe.h #1.25:1.26
@@ -64,4 +64,5 @@
#include <signal.h> /* for siginfo_t */
#include <linux/timex.h> /* for adjtimex */
+#include <linux/fb.h> /* for fb_* structs */
#define __USE_LARGEFILE64
|
|
From: Tom H. <th...@cy...> - 2004-04-21 15:40:02
|
CVS commit by thughes:
Change the debugger attachment code to send the STOP signal to the
forked process before using ptrace() to continue it, instead of asking
ptrace to deliver it, as that doesn't seem to work on some versions
of linux.
CCMAIL: 778...@bu...
M +2 -1 vg_main.c 1.150
--- valgrind/coregrind/vg_main.c #1.149:1.150
@@ -351,5 +351,6 @@ void VG_(start_debugger) ( Int tid )
WIFSTOPPED(status) && WSTOPSIG(status) == SIGSTOP &&
ptrace(PTRACE_SETREGS, pid, NULL, ®s) == 0 &&
- ptrace(PTRACE_DETACH, pid, NULL, SIGSTOP) == 0) {
+ kill(pid, SIGSTOP) == 0 &&
+ ptrace(PTRACE_DETACH, pid, NULL, 0) == 0) {
Char pidbuf[15];
Char file[30];
|
|
From: Tom H. <th...@cy...> - 2004-04-21 15:16:48
|
CVS commit by thughes:
Initialise %cs, %ds and %ss in the virtual machine to match the values
supplied by the operating system for the code, data and stack segments.
Explicit references using these segments still won't work but they
will at least produce an assertion to indicate that they aren't
supported instead of raising a segmentation fault in the target
program because of an apparent privilege violation.
M +12 -0 vg_main.c 1.149
--- valgrind/coregrind/vg_main.c #1.148:1.149
@@ -2428,4 +2428,16 @@ static void init_baseBlock ( Addr client
VGOFF_(m_gs) = alloc_BaB_1_set(0);
+ /* initialise %cs, %ds and %ss to point at the operating systems
+ default code, data and stack segments */
+ asm volatile("movw %%cs, %0"
+ :
+ : "m" (VG_(baseBlock)[VGOFF_(m_cs)]));
+ asm volatile("movw %%ds, %0"
+ :
+ : "m" (VG_(baseBlock)[VGOFF_(m_ds)]));
+ asm volatile("movw %%ss, %0"
+ :
+ : "m" (VG_(baseBlock)[VGOFF_(m_ss)]));
+
VG_(register_noncompact_helper)( (Addr) & VG_(do_useseg) );
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-21 09:17:29
|
On Wed, 21 Apr 2004, Doug Rabson wrote: > Shouldn't that be --tool=memcheck? yep, fixed, thanks |
|
From: Nicholas N. <nj...@ca...> - 2004-04-21 09:17:24
|
CVS commit by nethercote:
fix typo
M +1 -1 README 1.19
--- valgrind/README #1.18:1.19
@@ -86,5 +86,5 @@
require that.
- 6. See if it works. Try "valgrind --tool-memcheck ls -l". Either
+ 6. See if it works. Try "valgrind --tool=memcheck ls -l". Either
this works, or it bombs out with some complaint. In that case,
please let us know (see valgrind.kde.org/bugs.html).
|
|
From: Doug R. <df...@nl...> - 2004-04-21 09:12:54
|
On Wednesday 21 April 2004 08:22, Nicholas Nethercote wrote: > CVS commit by nethercote: > > Update for compulsory --tool > > > M +3 -3 README 1.18 > > > --- valgrind/README #1.17:1.18 > @@ -86,7 +86,7 @@ > require that. > > - 6. See if it works. Try "valgrind ls -l". Either this works, > - or it bombs out with some complaint. In that case, please let > - us know (see valgrind.kde.org/bugs.html). > + 6. See if it works. Try "valgrind --tool-memcheck ls -l". Either > + this works, or it bombs out with some complaint. In that case, > + please let us know (see valgrind.kde.org/bugs.html). > > Important! Do not move the valgrind installation into a place Shouldn't that be --tool=memcheck? |
|
From: Nicholas N. <nj...@ca...> - 2004-04-21 07:25:49
|
CVS commit by nethercote: Remove Annelid; it can go under "Other", and no-one is using it anyway. M +0 -1 survey2 1.8 --- devel-home/valgrind/survey2 #1.7:1.8 @@ -102,5 +102,4 @@ Calltree/KCachegrind : Massif : -Annelid : other : |
|
From: Nicholas N. <nj...@ca...> - 2004-04-21 07:22:54
|
CVS commit by nethercote:
Update for compulsory --tool
M +3 -3 README 1.18
--- valgrind/README #1.17:1.18
@@ -86,7 +86,7 @@
require that.
- 6. See if it works. Try "valgrind ls -l". Either this works,
- or it bombs out with some complaint. In that case, please let
- us know (see valgrind.kde.org/bugs.html).
+ 6. See if it works. Try "valgrind --tool-memcheck ls -l". Either
+ this works, or it bombs out with some complaint. In that case,
+ please let us know (see valgrind.kde.org/bugs.html).
Important! Do not move the valgrind installation into a place
|
|
From: Robert W. <rj...@du...> - 2004-04-21 07:13:14
|
Hi folks,
I've started looking at getting Valgrind running on AMD64 machines,
since my main desktop is now an Athlon64 box. The first thing that
seemed useful was to get Valgrind running with 32-bit executables on
AMD64 machines. I've put a one-line patch on my web site that does
this. I've only tested this under Fedora Core 1 with a 2.6.5 kernel.=20
I'd appreciate if someone could give it a spin with another distribution
and/or a 2.4 kernel. Some notes:
* You need to build on an x86 box with compatible libraries to the
box you plan on testing on - you still can't build on an AMD64
machine.
* It is just a mechanism for Valgrinding 32-bit executables on an
AMD64 machine. 64-bit executables are a LONG way off... :-)
* Some (about 6) of the regression tests fail. I haven't really
investigated these yet. Some appear to be library
incompatibilities, as I was building the tests on a RedHat 9 for
x86 machine and executing them on a Fedora Core 1 for AMD64
machine. Others appear to be a bit more serious.
BTW: this patch doesn't actually break regular Valgrind-on-x86 in any
way, so if it seems OK, I'll commit it in the next few days, after I've
heard back from people.
Regards,
Robert.
--=20
Robert Walsh
Amalgamated Durables, Inc. - "We don't make the things you buy."
Email: rj...@du...
|
|
From: <js...@ac...> - 2004-04-21 03:04:31
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-04-21 04:00:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 152 tests, 12 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-04-21 02:38:46
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-04-21 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 152 tests, 12 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-04-21 02:23:29
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-04-21 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 2 stderr failures, 1 stdout failure ================= memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-21 02:18:34
|
Nightly build on audi ( Red Hat 9 ) started at 2004-04-21 03:15:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 1 stderr failure, 0 stdout failures ================= corecheck/tests/pth_cancel2 (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-21 02:13:19
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-04-21 03:10:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 4 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-21 02:08:24
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-04-21 03:05:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 5 stderr failures, 1 stdout failure ================= memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-21 02:07:24
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-04-21 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |