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
(23) |
2
(40) |
3
(17) |
4
(10) |
|
5
(14) |
6
(41) |
7
(26) |
8
(23) |
9
(15) |
10
(25) |
11
(14) |
|
12
(23) |
13
(11) |
14
(18) |
15
(21) |
16
(18) |
17
(8) |
18
(14) |
|
19
(16) |
20
(15) |
21
(12) |
22
(11) |
23
(8) |
24
(11) |
25
(12) |
|
26
(9) |
27
(17) |
28
(31) |
29
(16) |
30
(10) |
31
(17) |
|
|
From: Nicholas N. <nj...@cs...> - 2006-03-05 22:39:08
|
On Wed, 1 Mar 2006, Duncan Sands wrote:
> Consider a system call like mmap. The fd
> parameter is not accessed if MAP_ANONYMOUS
> is set in flags, so it doesn't matter if it
> contains junk. However valgrind complains
> that
> "Syscall param mmap2(fd) contains uninitialised byte(s)"
> This seems to be due to the following
>
> PRE_REG_READ6(long, "mmap2",
> unsigned long, start, unsigned long, length,
> unsigned long, prot, unsigned long, flags,
> unsigned long, fd, unsigned long, offset);
>
> at line 1303 of syswrap-x86-linux.c, which appears to check
> that none of the arguments contains junk.
>
> Is this a valgrind bug, or is there a policy of checking all
> syscall arguments regardless of whether they will be used or
> not?
Here's the code for open(), which only sometimes looks at the 3rd argument:
if (ARG2 & VKI_O_CREAT) {
// 3-arg version
PRINT("sys_open ( %p(%s), %d, %d )",ARG1,ARG1,ARG2,ARG3);
PRE_REG_READ3(long, "open",
const char *, filename, int, flags, int, mode);
} else {
// 2-arg version
PRINT("sys_open ( %p(%s), %d )",ARG1,ARG1,ARG2);
PRE_REG_READ2(long, "open",
const char *, filename, int, flags);
}
So I think the current policy is to only check the arguments that are used
by the kernel, and that the mmap() wrapper was not implementing that policy
correctly. I also appreciate John's point about leaking information into
the kernel.
Nick
|
|
From: Bryan M. <om...@br...> - 2006-03-05 22:36:35
|
Dear Valgrind Developers List, Further to my last - 64 bit crash is fixed - download again if you already picked up the patch before 22:15 GMT today. This is now (briefly) tested on x86_64/AMD64 and it works (kwrite runs properly). Anyone out there with 64 bit machines willing to give this a spin, I would love to hear how you get on. thanks in advance, Bryan "Brain Murders" Meredith Bryan Meredith wrote: > Dear Valgrind Developers List, > > Further to my last - 64 bit crash is fixed - download again if you > already picked up the patch before 22:15 GMT today. > > This is now (briefly) tested on x86_64/AMD64 and it works (kwrite runs > properly). > > Anyone out there with 64 bit machines willing to give this a spin, I > would love to hear how you get on. > > thanks in advance, > Bryan "Brain Murders" Meredith > > > Bryan Meredith wrote: >> Dear Valgrind Developers List, >> >> for those interested, you can find a patch against svn here: >> >> http://www.brainmurders.eclipse.co.uk/omega_BETA_01.patch.gz >> >> This is now BETA software! I can now successfully run kwrite and >> various other apps in all their glory. >> >> Note that this patches VEX in order to sort out an issue I have with >> popping values off the stack. >> >> Still only tested on x86 so far as I am having problems with builds on >> x86_64. I hope to get to the bottom of this next week sometime but it >> affects memcheck as well as omega so its something pretty fundamental >> - valgrind segfaults on startup with a bad memory access to address 0x09. >> >> I have updated the docs (small but to the point) so please have a read. >> >> For best results, compile your program to be tested with -O0 -g and >> make sure that memcheck complains about nothing but memory leaks... >> >> You might want to pipe the output into a file as there can be rather a >> lot of it. >> >> Note that the --db-attach option is functional so you can attach the >> debugger just as the leak is about to happen (but note comments about >> registers in the docs). >> >> I really need your feedback on this please. Things that I am extremely >> keen to hear about are comments on the output - what would be the most >> useful? General comments are also most welcome so if anyone can spare >> the time to give this a whizz, please let me know how you get on. >> >> Patches are also most welcome along with feature requests. >> >> >> Thanks in advance, >> Bryan "Brain Murders" Meredith >> > |
|
From: <sv...@va...> - 2006-03-05 19:20:17
|
Author: sewardj
Date: 2006-03-05 19:20:08 +0000 (Sun, 05 Mar 2006)
New Revision: 1580
Log:
merge r1579 (Implement mtocrf/mfocrf.)
Modified:
branches/VEX_3_1_BRANCH/priv/guest-ppc32/toIR.c
Modified: branches/VEX_3_1_BRANCH/priv/guest-ppc32/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VEX_3_1_BRANCH/priv/guest-ppc32/toIR.c 2006-03-01 18:58:39 U=
TC (rev 1579)
+++ branches/VEX_3_1_BRANCH/priv/guest-ppc32/toIR.c 2006-03-05 19:20:08 U=
TC (rev 1580)
@@ -3760,14 +3760,23 @@
break;
}
=20
- case 0x013: // mfcr (Move from Condition Register, PPC32 p467)
- if (b11to20 !=3D 0) {
- vex_printf("dis_proc_ctl(PPC32)(mfcr,b11to20)\n");
- return False;
+ case 0x013:
+ // b11to20=3D=3D0: mfcr (Move from Cond Register, PPC32 p467)
+ // b20=3D=3D1 & b11=3D=3D0: mfocrf (Move from One CR Field)
+ // However it seems that the 'mfcr' behaviour is an acceptable
+ // implementation of mfocr (from the 2.02 arch spec)
+ if (b11to20 =3D=3D 0) {
+ DIP("mfcr r%u\n", rD_addr);
+ putIReg( rD_addr, getSPR( PPC32_SPR_CR ) );
+ break;
}
- DIP("mfcr r%d\n", rD_addr);
- putIReg( rD_addr, getSPR( PPC32_SPR_CR ) );
- break;
+ if (b20 =3D=3D 1 && b11 =3D=3D 0) {
+ DIP("mfocrf r%u,%u\n", rD_addr, CRM);
+ putIReg( rD_addr, getSPR( PPC32_SPR_CR ) );
+ break;
+ }
+ /* not decodable */
+ return False;
=20
/* XFX-Form */
case 0x153: // mfspr (Move from Special-Purpose Register, PPC32 p470)
@@ -3838,14 +3847,27 @@
break;
}
=20
- case 0x090: { // mtcrf (Move to Condition Register Fields, PPC32 p477=
)
+ case 0x090: {
+ // b20=3D=3D0: mtcrf (Move to Cond Register Fields, PPC32 p477)
+ // b20=3D=3D1: mtocrf (Move to One Cond Reg Field)
Int cr;
UChar shft;
- if (b11 !=3D 0 || b20 !=3D 0) {
- vex_printf("dis_proc_ctl(PPC32)(mtcrf,b11|b20)\n");
+ if (b11 !=3D 0)
return False;
+ if (b20 =3D=3D 1) {
+ /* ppc64 v2.02 spec says mtocrf gives undefined outcome if >
+ 1 field is written. It seems more robust to decline to
+ decode the insn if so. */
+ switch (CRM) {
+ case 0x01: case 0x02: case 0x04: case 0x08:
+ case 0x10: case 0x20: case 0x40: case 0x80:
+ break;
+ default:
+ return False;
+ }
}
- DIP("mtcrf 0x%x,r%d\n", CRM, rS_addr);
+ DIP("%s 0x%x,r%u\n", b20=3D=3D1 ? "mtocrf" : "mtcrf",
+ CRM, rS_addr);
/* Write to each field specified by CRM */
for (cr =3D 0; cr < 8; cr++) {
if ((CRM & (1 << (7-cr))) =3D=3D 0)
@@ -3857,6 +3879,9 @@
break;
}
=20
+
+
+
case 0x1D3: // mtspr (Move to Special-Purpose Register, PPC32 p483)
=20
switch (SPR) { // Choose a register...
|
|
From: Bryan M. <om...@br...> - 2006-03-05 18:21:09
|
Dear Valgrind Developers List, for those interested, you can find a patch against svn here: http://www.brainmurders.eclipse.co.uk/omega_BETA_01.patch.gz This is now BETA software! I can now successfully run kwrite and various other apps in all their glory. Note that this patches VEX in order to sort out an issue I have with popping values off the stack. Still only tested on x86 so far as I am having problems with builds on x86_64. I hope to get to the bottom of this next week sometime but it affects memcheck as well as omega so its something pretty fundamental - valgrind segfaults on startup with a bad memory access to address 0x09. I have updated the docs (small but to the point) so please have a read. For best results, compile your program to be tested with -O0 -g and make sure that memcheck complains about nothing but memory leaks... You might want to pipe the output into a file as there can be rather a lot of it. Note that the --db-attach option is functional so you can attach the debugger just as the leak is about to happen (but note comments about registers in the docs). I really need your feedback on this please. Things that I am extremely keen to hear about are comments on the output - what would be the most useful? General comments are also most welcome so if anyone can spare the time to give this a whizz, please let me know how you get on. Patches are also most welcome along with feature requests. Thanks in advance, Bryan "Brain Murders" Meredith |
|
From: Julian S. <js...@ac...> - 2006-03-05 16:57:35
|
> By this time I obtained a copy from the trunk and added (locally) the
> 'drd' tool to the trunk. ('drd' is short for data race detection -- is this
> a good name ?)
Seems as good as any.
> I tried to uncomment the three functions at the end of
> coregrind/vg_preloaded.c, but I got the following compiler errors when I
> tried this:
> vg_preloaded.c:90: warning: implicit declaration of function
> 'VALGRIND_GET_NRADDR'
> vg_preloaded.c:93: error: invalid initializer
> vg_preloaded.c: In function
> '_vgwZZ_libpthreadZdsoZd0_pthreadZumutexZulock': vg_preloaded.c:105:
> warning: initialization from incompatible pointer type vg_preloaded.c:108:
> error: invalid initializer
> vg_preloaded.c: In function
> '_vgwZZ_libpthreadZdsoZd0_pthreadZumutexZuunlock':
> vg_preloaded.c:120: warning: initialization from incompatible pointer type
> vg_preloaded.c:124: error: invalid initializer
Yeh, that code is a bit out of date. The patch I sent earlier today
fixes that (you need to change "void* fn" to "OrigFn fn").
> - Eraser attempts to verify a locking discipline, that is, whether or not
> there is a mutex associated with each shared variable and that this mutex
> is locked every time the variable is accessed.
> - DIOTA does not attempt to do any verifications at the program level, but
> only verifies one particular execution of a program. It verifies whether
> accesses to the same variable by different threads are ordered by
> synchronization actions.
They sound very similar. I guess there are details ..
> So the short answer is: I'd like to be informed about every event that
> imposes an ordering of events between threads. The DIOTA tool instruments
> the following calls:
> - pthread_create(), pthread_join(), pthread_exit().
> - pthread_mutex_lock(), pthread_mutex_unlock(), pthread_mutex_trylock().
> - pthread_cond_wait(), pthread_cond_timedwait().
> - sem_wait(), sem_post(), sem_trywait().
> - pthread_barrier_wait().
>
> The following are IMHO also interesting:
> - pthread_rwlock_rdlock(), pthread_rwlock_tryrdlock(),
> pthread_rwlock_trywrlock(), pthread_rwlock_unlock(),
> pthread_rwlock_wrlock().
> - pthread_spin_lock(), pthread_spin_trylock(), pthread_spin_unlock().
>
> Is it possible to send notifications for all these functions ?
In principle yes. As per my earlier posting you should be able to hack
up wrappers and notifications for any of them yourself; however I
think it would be good to get the thing to work well enough so we can
evaluate it with just the basics (lock, unlock, create, join).
> By the way, do you have any idea which algorithm is implemented in Intel's
> Thread Checker (part of VTune) ?
Absolutely no idea.
> I have used VTune for testing a
> cross-platform threading library, and every time VTune reported a data race
> it was a real one.
That's impressive.
J
|
|
From: Julian S. <js...@ac...> - 2006-03-05 14:09:52
|
> Good news: my data race detection tool, although far from finished, is
> already producing some output. It can already show the list of
> conflicting accesses between threads.
Cool.
> pthread_mutex_unlock() ? Is anyone willing to make
> VG_(track_{pre|post}_mutex_{lock|unlock}) working again ?
Attached is a patch against r5712 which does track_{pre|post}_mutex_lock
and track_post_mutex_unlock. There is no track_pre_mutex_unlock
(since it never blocks) although one could be created if you want.
Tracking pthread_join is not done yet. It's more difficult; I
have not yet figured out how to find out the TId of the thread
being joined to. We know the pthread_t of that thread, but
I don't see an obvious way to find its TId (valgrind's internal
thread-id).
Anyway, this should give some idea how to build/modify the
notifications you need.
- vg_preloaded.c runs on the simulated CPU, and intercepts (wraps)
the relevant pthread functions.
- These wrappers use the client request mechanism to pass event
notifications to the scheduler (scheduler.c).
- The scheduler passes these notifications on to the tool, if it
has asked to see them.
I haven't committed this. Maybe you can mess with the patch to get
it more like you want.
J
|
|
From: <js...@ac...> - 2006-03-05 10:20:46
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-03-05 02:00:01 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 == 193 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <js...@ac...> - 2006-03-05 04:01:11
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-03-05 03:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 223 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-03-05 03:51:10
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-03-05 03:00:03 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 == 245 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <to...@co...> - 2006-03-05 03:43:42
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-03-05 03:30: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 == 225 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <js...@ac...> - 2006-03-05 03:43:33
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-03-05 04:40:00 CET Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... failed Last 20 lines of verbose log follow echo mpiwrap.c: In function `walk_type': mpiwrap.c:351: warning: cast to pointer from integer of different size mpiwrap.c: In function `_vgwZU_libmpiZdsoZa_PMPI_Send': mpiwrap.c:614: warning: implicit declaration of function `CALL_FN_W_6W' mpiwrap.c: In function `_vgwZU_libmpiZdsoZa_PMPI_Recv': mpiwrap.c:639: warning: implicit declaration of function `CALL_FN_W_7W' mpiwrap.c: In function `_vgwZU_libmpiZdsoZa_PMPI_Waitall': mpiwrap.c:942: warning: implicit declaration of function `CALL_FN_W_WWW' mpiwrap.c: In function `_vgwZU_libmpiZdsoZa_PMPI_Iprobe': mpiwrap.c:981: warning: implicit declaration of function `CALL_FN_W_5W' mpiwrap.c: In function `_vgwZU_libmpiZdsoZa_PMPI_Sendrecv': mpiwrap.c:1022: warning: implicit declaration of function `CALL_FN_W_12W' mpiwrap.c: In function `_vgwZU_libmpiZdsoZa_PMPI_Gather': mpiwrap.c:1116: warning: implicit declaration of function `CALL_FN_W_8W' mpicc: No such file or directory make[2]: *** [libmpiwrap.so] Error 1 make[2]: Leaving directory `/home/sewardj/Nightly/valgrind/auxprogs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sewardj/Nightly/valgrind' make: *** [all] Error 2 |
|
From: Tom H. <th...@cy...> - 2006-03-05 03:32:50
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-03-05 03:15:02 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 == 224 tests, 21 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-03-05 03:25:36
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-03-05 03:10:07 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 == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-03-05 03:22:18
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-03-05 03:05:14 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 == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |