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
(11) |
2
(8) |
|
3
(8) |
4
(8) |
5
(8) |
6
(19) |
7
(17) |
8
(12) |
9
(10) |
|
10
(15) |
11
(18) |
12
(14) |
13
(16) |
14
(24) |
15
(16) |
16
(12) |
|
17
(25) |
18
(23) |
19
(12) |
20
(10) |
21
(9) |
22
(12) |
23
(13) |
|
24
(19) |
25
(7) |
26
(39) |
27
(22) |
28
(22) |
29
(16) |
30
(13) |
|
31
(23) |
|
|
|
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2006-12-15 22:25:21
|
On Fri, 15 Dec 2006, Julian Seward wrote: > shows that pthread_spin_init and pthread_spin_unlock have the same > address, and the --trace-symtab output > >> choosing between 'pthread_spin_unlock' and 'pthread_spin_init' >> choosing between 'pthread_spin_unlock' and 'pthread_spin_init' > > confirms it (because it says it is having to make a decision about > which name to associate with that address. Unfortunately the message > is a bit stupid and does not say which name it did choose.) I think it chooses the shorter one. Reason being is that often the two names will be "foo" vs "foo@@GLIBC2.1" or something like that. Nick |
|
From: Bart V. A. <bar...@gm...> - 2006-12-15 16:21:37
|
On 12/15/06, Julian Seward <js...@ac...> wrote: > > Secondly, > > > --5596-- 0x040450E0 (pthread_spin_init ) W-> 0x0401FDE2 > > shows that (1) pthread_spin_init was chosen, and (2) you have an > active wrapper for it. Observe that the page offset (0x0E0) is the > same as objdump said, which helps us be sure it's the right symbol. > Hence eventually > > > --5596-- REDIR: 0x40450E0 (pthread_spin_init) redirected to 0x401FDE2 > > (pthread_spin_init) > > Isn't that what you want? By this time I found out that the pthread_spin_init() wrapper is called when the client calls pthread_spin_unlock(). Not really what I was hoping for, but it allowed me to add support for spinlocks to drd. Sorry for my confusion and that I didn't see this earlier. Bart. |
|
From: Julian S. <js...@ac...> - 2006-12-15 15:03:59
|
(oops, forgot to cc -dev) On Friday 15 December 2006 15:12, Julian Seward wrote: > > > I made a suggestion a few months back called "danger-set" (incorporated > > > as comments in the drd patch) and that would allow drd to say precisely > > > when the second access to a contended location happened. Then it would > > > make sense to attach a debugger. But as it stands I don't see that > > > attaching a debugger would give a meaningful result. > > > > Hi Julian, it's only to try to work out which variable lives at the > > memory location. Perhaps you know of a better way? > > Ah, ok. I guess that would work OK for globals and heap-resident > data, but not for stack allocated data, since the debugger is started > arbitrarily later than the race point. > > One possibility is to improve V's debug-info reader so it can read > data addresses and make sense of DWARF2/3 data type info. That would > help; we had a similar thing for stabs in the past. It's a significant > amount of work though. > > Another possible improvement is to implement this danger-set > algorithm. That would allow drd to pinpoint the exact instruction > causing the second and all subsequent memory accesses to a > contended memory location, hence give you an exact call stack to > where it happened. That should help a lot in making sense of > drd output. > > J |
|
From: Julian S. <js...@ac...> - 2006-12-15 14:22:30
|
Bart As Tom says, --trace-redir=yes is your friend here. It tells you the "TOPSPECS" -- that is, the redirection specifications it knows about, and the "ACTIVE" state -- that is, the redirections that are actually active right now. If you haven't already done so, you should read section 2.10 of the manual (http://www.valgrind.org/docs/manual/manual-core.html#manual-core.wrapping) and particularly section 2.10.4, since you are making extensive use of function wrapping. I think you have what you want. Firstly > $ objdump -T /lib/libpthread.so.0 |grep pthread_spin > 000090e0 g DF .text 0000000d GLIBC_2.2 pthread_spin_unlock > 000090e0 g DF .text 0000000d GLIBC_2.2 pthread_spin_init shows that pthread_spin_init and pthread_spin_unlock have the same address, and the --trace-symtab output > choosing between 'pthread_spin_unlock' and 'pthread_spin_init' > choosing between 'pthread_spin_unlock' and 'pthread_spin_init' confirms it (because it says it is having to make a decision about which name to associate with that address. Unfortunately the message is a bit stupid and does not say which name it did choose.) Secondly, > --5596-- 0x040450E0 (pthread_spin_init ) W-> 0x0401FDE2 shows that (1) pthread_spin_init was chosen, and (2) you have an active wrapper for it. Observe that the page offset (0x0E0) is the same as objdump said, which helps us be sure it's the right symbol. Hence eventually > --5596-- REDIR: 0x40450E0 (pthread_spin_init) redirected to 0x401FDE2 > (pthread_spin_init) Isn't that what you want? J |
|
From: Duncan S. <bal...@fr...> - 2006-12-15 14:18:40
|
> Does it make any sense to attach a debugger in drd? A race does not > have a single unique source location; it only "happens" when a > thread T2 accesses a memory location that some other thread T1 has > also accessed, and there is no synchronising event to sequence these > accesses. Currently AIUI drd will tell you this happened arbitrarily > later than the actual accesses, when it compares the memory-access > sets for the two thread (segments). > > I made a suggestion a few months back called "danger-set" (incorporated > as comments in the drd patch) and that would allow drd to say precisely > when the second access to a contended location happened. Then it would > make sense to attach a debugger. But as it stands I don't see that > attaching a debugger would give a meaningful result. Hi Julian, it's only to try to work out which variable lives at the memory location. Perhaps you know of a better way? Ciao, Duncan. |
|
From: Julian S. <js...@ac...> - 2006-12-15 14:04:58
|
On Friday 15 December 2006 07:43, Duncan Sands wrote: > > > Being able to attach a debugger just after a race is detected would > > > indeed be a nice feature. > > > > The core's error-handling mechanism allows this by default. Just use > > --db-attach (or whatever it's called). > > I tried it, but it doesn't ask if it should attach the debugger > when drd prints a race, only if you hit ctrl-c. Does it make any sense to attach a debugger in drd? A race does not have a single unique source location; it only "happens" when a thread T2 accesses a memory location that some other thread T1 has also accessed, and there is no synchronising event to sequence these accesses. Currently AIUI drd will tell you this happened arbitrarily later than the actual accesses, when it compares the memory-access sets for the two thread (segments). I made a suggestion a few months back called "danger-set" (incorporated as comments in the drd patch) and that would allow drd to say precisely when the second access to a contended location happened. Then it would make sense to attach a debugger. But as it stands I don't see that attaching a debugger would give a meaningful result. J |
|
From: Duncan S. <bal...@fr...> - 2006-12-15 07:43:22
|
> > Being able to attach a debugger just after a race is detected would > > indeed be a nice feature. > > The core's error-handling mechanism allows this by default. Just use > --db-attach (or whatever it's called). I tried it, but it doesn't ask if it should attach the debugger when drd prints a race, only if you hit ctrl-c. Ciao, Duncan. |
|
From: <js...@ac...> - 2006-12-15 05:05:03
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-12-15 04: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 == 250 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) ================================================= == Results from 24 hours ago == ================================================= 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 == 250 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Dec 15 04:48:18 2006 --- new.short Fri Dec 15 05:05:08 2006 *************** *** 10,12 **** ! == 250 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) --- 10,12 ---- ! == 250 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) *************** *** 18,19 **** --- 18,20 ---- none/tests/mremap2 (stdout) + none/tests/pth_detached (stdout) |
|
From: <js...@ac...> - 2006-12-15 04:58:16
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-12-15 09:00: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 == 215 tests, 10 stderr failures, 7 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/jm-int (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <sv...@va...> - 2006-12-15 04:37:28
|
Author: njn
Date: 2006-12-15 04:37:25 +0000 (Fri, 15 Dec 2006)
New Revision: 6401
Log:
Remove defunct constant.
Modified:
trunk/include/pub_tool_tooliface.h
trunk/memcheck/mc_main.c
Modified: trunk/include/pub_tool_tooliface.h
=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
--- trunk/include/pub_tool_tooliface.h 2006-12-14 03:29:18 UTC (rev 6400)
+++ trunk/include/pub_tool_tooliface.h 2006-12-15 04:37:25 UTC (rev 6401)
@@ -445,7 +445,7 @@
/* Part of the core from which this call was made. Useful for determini=
ng
what kind of error message should be emitted. */
typedef
- enum { Vg_CoreStartup, Vg_CorePThread, Vg_CoreSignal, Vg_CoreSysCall,
+ enum { Vg_CoreStartup, Vg_CoreSignal, Vg_CoreSysCall,
Vg_CoreTranslate, Vg_CoreClientReq }
CorePart;
=20
Modified: trunk/memcheck/mc_main.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
--- trunk/memcheck/mc_main.c 2006-12-14 03:29:18 UTC (rev 6400)
+++ trunk/memcheck/mc_main.c 2006-12-15 04:37:25 UTC (rev 6401)
@@ -2468,7 +2468,6 @@
/*isUnaddr*/True, s );
break;
=20
- case Vg_CorePThread:
case Vg_CoreSignal:
mc_record_core_mem_error( tid, /*isUnaddr*/True, s );
break;
@@ -2496,7 +2495,6 @@
break;
=20
case Vg_CoreClientReq: // Kludge: make this a CoreMemErr
- case Vg_CorePThread:
mc_record_core_mem_error( tid, isUnaddr, s );
break;
=20
|
|
From: Tom H. <to...@co...> - 2006-12-15 03:55:23
|
Nightly build on dunsmere ( athlon, Fedora Core 6 ) started at 2006-12-15 03:30:05 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 == 252 tests, 5 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) |
|
From: Tom H. <th...@cy...> - 2006-12-15 03:35:29
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-12-15 03:00:03 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 282 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/tls (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 282 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Dec 15 03:13:17 2006 --- new.short Fri Dec 15 03:33:15 2006 *************** *** 8,10 **** ! == 282 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 282 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 16,17 **** --- 16,18 ---- none/tests/mremap2 (stdout) + none/tests/tls (stdout) |
|
From: Tom H. <th...@cy...> - 2006-12-15 03:25:19
|
Nightly build on dellow ( x86_64, Fedora Core 6 ) started at 2006-12-15 03:10:03 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 280 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 280 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Dec 15 03:16:40 2006 --- new.short Fri Dec 15 03:23:05 2006 *************** *** 8,10 **** ! == 280 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 280 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 14,16 **** none/tests/mremap2 (stdout) - none/tests/pth_detached (stdout) --- 14,15 ---- |
|
From: Tom H. <th...@cy...> - 2006-12-15 03:24:20
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-12-15 03:15:01 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccl35NX3.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl35NX3.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl35NX3.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl35NX3.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl35NX3.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl35NX3.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl35NX3.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl35NX3.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.6024/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.6024/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.6024/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.6024/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.6024/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccd9AyYN.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccd9AyYN.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccd9AyYN.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccd9AyYN.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccd9AyYN.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccd9AyYN.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccd9AyYN.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccd9AyYN.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.6024/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.6024/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.6024/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.6024/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.6024/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Dec 15 03:18:52 2006 --- new.short Fri Dec 15 03:22:37 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccd9AyYN.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccd9AyYN.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccd9AyYN.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccd9AyYN.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccd9AyYN.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccd9AyYN.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccd9AyYN.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccd9AyYN.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccl35NX3.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl35NX3.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl35NX3.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl35NX3.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl35NX3.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl35NX3.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl35NX3.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl35NX3.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-12-15 03:19:03
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-12-15 03:05:04 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 == 280 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2006-12-15 01:16:36
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2006-12-15 02:00:01 CET 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 == 221 tests, 6 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-int (stdout) none/tests/ppc64/jm-int (stdout) |