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
(26) |
2
(35) |
3
(18) |
4
(14) |
|
5
(12) |
6
(13) |
7
(11) |
8
(15) |
9
(8) |
10
(13) |
11
(25) |
|
12
(13) |
13
(24) |
14
(7) |
15
(6) |
16
(8) |
17
(6) |
18
(7) |
|
19
(8) |
20
(7) |
21
(5) |
22
(7) |
23
(6) |
24
(7) |
25
(6) |
|
26
(7) |
27
(7) |
28
(5) |
29
(5) |
30
(5) |
|
|
|
From: Jeremy F. <je...@go...> - 2004-09-08 21:11:51
|
On Thu, 2004-09-02 at 11:23 +0100, Julian Seward wrote: > One point to bear in mind is that the conversation that followed > appeared to be silently predicated on the assumption that Linux is > the only kernel we're interested in. We have to think beyond that: > I would love to make V available for MacOSX, and I bet (eg) the > OpenBSD folks would love to get their hands on an x86-openbsd > variant of Valgrind. Indeed, once Nick's current commit set goes > in, one interesting experiment would be to try an openbsd port. > Or freebsd (already exists) or netbsd. I don't think anything here is particularly kernel-dependent. The prerequisite is that there's an mmap syscall which allows us to define the placement of things in the address space. That's not a big ask. > Let's just forget about big-bang shadow allocation. It causes a whole > bunch of problems, we're not using it at the moment, and we don't have > a clear picture of where the cycle-level costs of shadow memory come > from anyway. For example, if shadow memory really kills us because > it jacks up the D1/L2 cache miss rates, then it's going to do so > regardless of the address translation scheme in use. Well, if we use direct map, then we're using the CPU's TLB rather than its D caches, so the tradeoff changes. And we're taking advantage of a CPU hotpath, which is presumably well optimised. "Manual" table indirects have locality patterns which match the client's memory access, so there isn't a huge increase in cache pressure. (ie, there's a doubling because of the data+shadow, but the table accesses only add 1 line per pagetable level.) The manual scheme adds I cache pressure linear to the number of table levels, if the table indirection is inlined. > > 4. Maybe make the --pointer-check=no change, if it seems useful. > > Well, I like the fact that currently the client can't trash V. > > Another thing to consider is how to achieve this portably, on > non-x86s. If the client address space is contained entirely in > 0 .. N-1, and N is a power of two, ANDing is obviously a cheap > solution. If the machine contains a scalar 'min' insn, then > we can do this cheaply for any N. There's the question of whether you simply want to prevent the client hitting Valgrind (by ANDing off the address bits), or actually detect the case and raise an error. J |
|
From: Jeremy F. <je...@go...> - 2004-09-08 21:01:14
|
On Wed, 2004-09-01 at 22:48 +0100, Nicholas Nethercote wrote: > >> Not sure it's worth doing it for now. How many people still use > >> stabs (on the platform we support...) ? > > > > Valgrind's dwarf support is pretty weak compared to the stabs support - > > there's nothing there to extract type information. > > But Helgrind is the only tool that uses the type information, and not many > people use Helgrind. Well, any tool which wants to describe an address symbolically could use that stuff. Its just that the other tools haven't been modified to do so. Actually, I thought memcheck/addrcheck do use it, but since they're mainly talking about values, it doesn't come up terribly often. > > We only need to resort to padding things out either before we gain full > > control (constraining ld.so to put things in the right place) > > I'm surprised that people with non-overcommitting kernels are not having a > problem with this step, but are having a problem with the big-bang shadow > memory allocation. I would have thought the padding done by stage1 would > involve more than 1.5GB worth of maps. They're mapped out of a file (mainly so we can identify them again later, but it has the nice effect of not triggering the overcommit logic). > >> BTW, now we are speaking of mem layout, I think it is very important > >> to keep in mind that it would be great to bootstrap V... > > > > You mean self-virtualization? That's a goal, but its tricky. > > PIE should help, though. That solves one problem, but Valgrind is its own worst enemy in this respect (it does a pile of things we'd hope to never see in a client). J |
|
From: Jeremy F. <je...@go...> - 2004-09-08 20:51:31
|
On Wed, 2004-09-01 at 22:44 +0100, Nicholas Nethercote wrote: > >> The downside of switching to incremental shadow memory is that it makes > >> direct-offset shadow addressing impossible, at least on 32-bit. > > > > The trouble is that memcheck&co do have a fixed ratio of shadow memory > > to real memory used. If the client uses its address space sparsely then > > it causes sparse (wasteful) use of the shadow memory, > > Exactly, that's why I'm arguing against direct-offset shadow addressing. > > > but since we get > > to place all the mmaps, we needn't make it have sparse memory use. The > > exception is if the client explicitly places its mappings, but I don't > > think that's common. > > > > So I know that people are running into memory problems, but it isn't > > clear to me that we can't solve them by using the address space more > > densely. > > (I assume you mean the client portion of the address space?) > > How do propose to use the client address space more densely? I can't see > how this would work. > > I'm not sure if we're all on the same wavelength with this stuff. OK, here's how I'm looking at it. The worse case is that the client uses two pages: one at 0x0, and one at client_end. This has an extremely sparse address space use, and while we only need two pages of shadow, the shadow_mapping occupies a lot of address space. The best case is that the client uses every byte of its mapped address space. In this case, the incremental shadow allocation will use the same amount of memory as the shadow mapping scheme, since every byte needs N bits of shadow. Now, since clients almost never use MAP_FIXED, it means that the address of every memory mapping is under our control. This means that if we place them in memory in a dense fashion, we can approach the best case memory usage density. This means that our original estimate of the amount of shadow memory needed (client size * N bits/byte) will be accurate, and we're making best use of the overall address space. So even if we allow the client address space to grow up as new things are mapped, and the shadow allocations to grow down, they'll always end up meeting at the same place anyway. > > Tools which don't have a fixed ratio (cachegrind) are another issue. > > They're not, technically, using shadow memory (since there isn't the 1:1 > > relationship between client addresses and shadow addresses), but > > Valgrind heap. > > I'm not sure why you say "technically"; Cachegrind (and Calltree, > Nulgrind, and Massif) don't use shadow memory at all. Much of the > discussion doesn't apply to them. However, they are still affected by > some of the rigidity problems eg. Calltree suffers from Problem P4. Wasn't cachegrind changed to allocate its stuff out of the shadow memory anyway? > (And "valgrind heap" is misleading because Valgrind no longer has a heap > as such; I took it out when I rejigged the memory layout stuff. It now > only allocates via maps.) Well, I'd still call that a heap, since its the thing under VG_(malloc). Doesn't really matter how the actual memory is requested from the kernel. > A problem with that is that on x86-64 executables are mapped very low, > 0x400000 I think (4MB), which doesn't leave enough room for even an 8MB > stack. I like the idea of putting it just below client_mapbase better. It would be interesting to know where Solaris-x86-64 puts things. J |
|
From: Jeremy F. <je...@go...> - 2004-09-08 20:41:54
|
On Thu, 2004-09-02 at 08:58 +0100, Nicholas Nethercote wrote: > The big-bang shadow alloc uses PROT_NONE + MAP_PRIVATE|MAP_ANON|MAP_FIXED. > For Memcheck the alloc-size is 1.5GB. > > The stage1 padding uses PROT_NONE + MAP_FIXED|MAP_PRIVATE, with a real > file. Typically, on my machine it does two mmaps, with a combined size of > 2.8GB. > > I wonder if the use of a file causes the difference. Yes, it does. The kernel is worried about whether there's somewhere to put the dirty pages as memory fills up. If there's no file backing, then the limit is phys.mem+swap. But if the mapping is backed by a file, then that mapping doesn't need to use swap if it is paged out. J |
|
From: Jeremy F. <je...@go...> - 2004-09-08 20:38:47
|
On Sat, 2004-09-04 at 00:08 +0100, Nicholas Nethercote wrote: > Originally we didn't use big-bang. Jeremy put it in with the FV memory > layout changes; AIUI he experimented with direct-offset shadow addressing > but the performance was no better, so the committed version didn't use it, > even though the code to support it was all present. It was part of my thinking about how to deal with a 64-bit address space. It would have been nice to get an unambiguous performance advantage for 32-bit processes, but it was about even, and the address space management problems are annoying. But the 2-level page table scheme doesn't scale well for 64-bit address spaces, and it duplicates something that the CPU will do for free anyway, so why not use the existing mechanism? Hence, direct mapping into a sparse(-ish) array. J |
|
From: Jeremy F. <je...@go...> - 2004-09-08 20:05:36
|
CVS commit by fitzhardinge:
Pull permissions checking out into a separate function to clean
things up a bit.
M +57 -35 ume.c 1.26 [POSSIBLY UNSAFE: printf]
--- valgrind/coregrind/ume.c #1.25:1.26
@@ -612,43 +612,28 @@ static int load_script(char *hdr, int le
}
-static int do_exec_inner(const char *exe, struct exeinfo *info)
+/*
+ Emulate the normal Unix permissions checking algorithm.
+
+ If owner matches, then use the owner permissions, else
+ if group matches, then use the group permissions, else
+ use other permissions.
+
+ Note that we can't deal with SUID/SGID, so we refuse to run them
+ (otherwise the executable may misbehave if it doesn't have the
+ permissions it thinks it does).
+*/
+static int check_perms(int fd)
{
- int fd;
- char buf[VKI_BYTES_PER_PAGE];
- int bufsz;
- int i;
- int ret;
struct stat st;
- static const struct {
- int (*match)(const char *hdr, int len);
- int (*load) ( char *hdr, int len, int fd2, const char *name,
- struct exeinfo *);
- } formats[] = {
- { match_ELF, load_ELF },
- { match_script, load_script },
- };
-
- fd = open(exe, O_RDONLY);
- if (fd == -1) {
- if (0)
- fprintf(stderr, "Can't open executable %s: %s\n",
- exe, strerror(errno));
- return errno;
- }
if (fstat(fd, &st) == -1)
return errno;
- else {
- uid_t uid = geteuid();
- gid_t gid = getegid();
- gid_t groups[32];
- int ngrp = getgroups(32, groups);
if (st.st_mode & (S_ISUID | S_ISGID)) {
- fprintf(stderr, "Can't execute suid/sgid executable %s\n", exe);
+ //fprintf(stderr, "Can't execute suid/sgid executable %s\n", exe);
return EACCES;
}
- if (uid == st.st_uid) {
+ if (geteuid() == st.st_uid) {
if (!(st.st_mode & S_IXUSR))
return EACCES;
@@ -656,7 +641,11 @@ static int do_exec_inner(const char *exe
int grpmatch = 0;
- if (gid == st.st_gid)
+ if (getegid() == st.st_gid)
grpmatch = 1;
- else
+ else {
+ gid_t groups[32];
+ int ngrp = getgroups(32, groups);
+ int i;
+
for(i = 0; i < ngrp; i++)
if (groups[i] == st.st_gid) {
@@ -664,4 +653,5 @@ static int do_exec_inner(const char *exe
break;
}
+ }
if (grpmatch) {
@@ -671,4 +661,36 @@ static int do_exec_inner(const char *exe
return EACCES;
}
+
+ return 0;
+}
+
+static int do_exec_inner(const char *exe, struct exeinfo *info)
+{
+ int fd;
+ char buf[VKI_BYTES_PER_PAGE];
+ int bufsz;
+ int i;
+ int ret;
+ static const struct {
+ int (*match)(const char *hdr, int len);
+ int (*load) ( char *hdr, int len, int fd2, const char *name,
+ struct exeinfo *);
+ } formats[] = {
+ { match_ELF, load_ELF },
+ { match_script, load_script },
+ };
+
+ fd = open(exe, O_RDONLY);
+ if (fd == -1) {
+ if (0)
+ fprintf(stderr, "Can't open executable %s: %s\n",
+ exe, strerror(errno));
+ return errno;
+ }
+
+ int err = check_perms(fd);
+ if (err != 0) {
+ close(fd);
+ return err;
}
|
|
From: Jeremy F. <je...@go...> - 2004-09-08 20:05:13
|
CVS commit by fitzhardinge:
When loading a -fpie executable, put it where info.exebase wants it, since
it doesn't have a useful address in its phdrs.
M +17 -6 ume.c 1.25
--- valgrind/coregrind/ume.c #1.24:1.25
@@ -406,8 +406,9 @@ static int load_ELF(char *hdr, int len,
struct elfinfo *e;
struct elfinfo *interp = NULL;
- ESZ(Addr) minaddr = ~0;
- ESZ(Addr) maxaddr = 0;
- ESZ(Addr) interp_addr = 0;
- ESZ(Word) interp_size = 0;
+ ESZ(Addr) exeoff = 0; /* offset between link address and load address */
+ ESZ(Addr) minaddr = ~0; /* lowest mapped address */
+ ESZ(Addr) maxaddr = 0; /* highest mapped address */
+ ESZ(Addr) interp_addr = 0; /* interpreter (ld.so) address */
+ ESZ(Word) interp_size = 0; /* interpreter size */
int i;
void *entry;
@@ -487,4 +488,14 @@ static int load_ELF(char *hdr, int len,
}
+ if (e->e.e_type == ET_DYN) {
+ /* PIE executable */
+ exeoff = info->exe_base - minaddr;
+ }
+
+ minaddr += exeoff;
+ maxaddr += exeoff;
+ info->phdr += exeoff;
+ info->entry += exeoff;
+
if (info->exe_base != info->exe_end) {
if (minaddr >= maxaddr ||
@@ -499,5 +510,5 @@ static int load_ELF(char *hdr, int len,
}
- info->brkbase = mapelf(e, 0); /* map the executable */
+ info->brkbase = mapelf(e, exeoff); /* map the executable */
if (info->brkbase == 0)
@@ -530,5 +541,5 @@ static int load_ELF(char *hdr, int len,
info->interp_base = (ESZ(Addr))base;
} else
- entry = (void *)e->e.e_entry;
+ entry = (void *)e->e.e_entry + exeoff;
info->exe_base = minaddr;
|
|
From: Jeremy F. <je...@go...> - 2004-09-08 20:04:08
|
CVS commit by fitzhardinge:
Use MAP_NORESERVE for potentially large mappings.
M +2 -2 ume.c 1.24
M +2 -2 vg_main.c 1.209
--- valgrind/coregrind/ume.c #1.23:1.24
@@ -129,5 +129,5 @@ static int fillgap(char *segstart, char
if (segstart > extra->fillgap_start) {
void* res = mmap(extra->fillgap_start, segstart - extra->fillgap_start,
- PROT_NONE, MAP_FIXED|MAP_PRIVATE,
+ PROT_NONE, MAP_FIXED|MAP_PRIVATE|MAP_NORESERVE,
extra->fillgap_padfile, 0);
check_mmap(res, extra->fillgap_start, segstart - extra->fillgap_start);
@@ -170,5 +170,5 @@ void as_pad(void *start, void *end, int
void* res = mmap(extra.fillgap_start,
extra.fillgap_end - extra.fillgap_start,
- PROT_NONE, MAP_FIXED|MAP_PRIVATE, padfile, 0);
+ PROT_NONE, MAP_FIXED|MAP_PRIVATE|MAP_NORESERVE, padfile, 0);
check_mmap(res, extra.fillgap_start,
extra.fillgap_end - extra.fillgap_start);
--- valgrind/coregrind/vg_main.c #1.208:1.209
@@ -442,5 +442,5 @@ static void layout_remaining_space(Addr
// Ban redzone
vres = mmap((void *)VG_(client_end), REDZONE_SIZE, PROT_NONE,
- MAP_FIXED|MAP_ANON|MAP_PRIVATE, -1, 0);
+ MAP_FIXED|MAP_ANON|MAP_PRIVATE|MAP_NORESERVE, -1, 0);
vg_assert((void*)-1 != vres);
@@ -453,5 +453,5 @@ static void layout_remaining_space(Addr
if (shadow_size != 0) {
vres = mmap((char *)VG_(shadow_base), shadow_size, PROT_NONE,
- MAP_PRIVATE|MAP_ANON|MAP_FIXED, -1, 0);
+ MAP_PRIVATE|MAP_ANON|MAP_FIXED|MAP_NORESERVE, -1, 0);
if ((void*)-1 == vres) {
fprintf(stderr,
|
|
From: Paul M. <pa...@sa...> - 2004-09-08 03:45:40
|
I wrote: > > I don't think so, at least not in scalar pipelines (SIMD ones maybe). > > PaulM, what's the deal on ppc? > > There is no single instruction, but I believe it can be done in a few > integer instructions without branches using some tricks with the carry > bit (I'm sure x86 could do something similar). There are altivec > instructions for signed, unsigned and floating point min and max. Thinking about this a bit more, what I could do on PPC is to use a conditional trap instruction. PPC has instructions that compare a register with either a register or a constant and generate a trap if a specified condition is met (signed or unsigned <, <=, ==, >=, >, or !=). We would then need a SIGTRAP handler to handle the (uncommon) error case. Paul. |
|
From: Tom H. <th...@cy...> - 2004-09-08 03:14:39
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-09-08 02:00:15 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow map_unmap: valgrind ./map_unmap mq: valgrind ./mq mremap: valgrind ./mremap munmap_exe: valgrind ./munmap_exe pth_blockedsig: valgrind ./pth_blockedsig pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv rlimit_nofile: valgrind ./rlimit_nofile seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 Could not read `smc1.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-09-08 02:55:40
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-09-08 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem 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 ---------------------------------------- == 174 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-09-08 02:25:14
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-09-08 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 179 tests, 8 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-08 02:19:29
|
Nightly build on audi ( Red Hat 9 ) started at 2004-09-08 03:15:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 179 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-08 02:13:23
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-09-08 03:10:02 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 sem: valgrind ./sem 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 ---------------------------------------- == 179 tests, 3 stderr failures, 0 stdout failures ================= helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-08 02:08:21
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-09-08 03:05:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 179 tests, 14 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) none/tests/coolo_sigaction (stderr) none/tests/gxx304 (stderr) make: *** [regtest] Error 1 |