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
(9) |
2
(16) |
|
3
(9) |
4
(8) |
5
(9) |
6
(10) |
7
(14) |
8
(10) |
9
(7) |
|
10
(14) |
11
(19) |
12
(22) |
13
(18) |
14
(20) |
15
(10) |
16
(12) |
|
17
(13) |
18
(7) |
19
(12) |
20
(13) |
21
(9) |
22
(12) |
23
(6) |
|
24
(5) |
25
(5) |
26
(6) |
27
(7) |
28
(9) |
29
(13) |
30
(21) |
|
From: Julian S. <js...@ac...> - 2006-09-17 19:31:30
|
> Regarding option (2): would it be that hard to provide a macro or client
> request such that a function can be called from client code without
> triggering function wrapping ?
Doable on {x86,amd64,ppc32}-linux, but on ppc64-linux and also AIX, the need
to find the correct TOC pointers makes it (much) more complicated, ugly and,
ultimately, fragile. I thought about it more this afternoon. I have a
different proposal below.
> On Sunday 17 September 2006 19:41, Bart Van Assche wrote:
> Regarding the data structure for the ThreadId <> pthread_t mapping:
> - Maybe an array with ThreadId as index and pthread_t as value is
> sufficient as data structure. If C++ code was allowed in Valgrind, I would
> make it a datastructure of type std::map<pthread_t, ThreadId>.
Ok, so some kind of mapping from pthread_t to ThreadId anyway. Exactly
how it's implemented isn't a big deal.
> - Regarding locking from within vg_preloaded.c: equivalents for
> pthread_mutex_lock(), unlock(), init() and destroy() should be sufficient.
At least for locking, adding two client requests, test-and-set, and
yield-this-thread, would make it easy to implement locking completely
independently of the application's thread library. I volunteer to
hack it up for you.
> Please note that pthread_cond_init(), destroy(), signal() and wait() also
> should be made available in vg_preloaded.c -- see also the comment about
> busy waiting in the valgrind core patch for drd (
> http://home.scarlet.be/%7Ebvassche/drd/valgrind-6012-core-2006-08-27.patch)
Noted. What primitives do we need to implement condition variables?
I never really understood them.
J
|
|
From: Bart V. A. <bar...@gm...> - 2006-09-17 18:41:27
|
Regarding the data structure for the ThreadId <> pthread_t mapping: - Maybe an array with ThreadId as index and pthread_t as value is sufficient as data structure. If C++ code was allowed in Valgrind, I would make it a datastructure of type std::map<pthread_t, ThreadId>. - Regarding locking from within vg_preloaded.c: equivalents for pthread_mutex_lock(), unlock(), init() and destroy() should be sufficient. Please note that pthread_cond_init(), destroy(), signal() and wait() also should be made available in vg_preloaded.c -- see also the comment about busy waiting in the valgrind core patch for drd ( http://home.scarlet.be/%7Ebvassche/drd/valgrind-6012-core-2006-08-27.patch). Regarding option (2): would it be that hard to provide a macro or client request such that a function can be called from client code without triggering function wrapping ? On 9/17/06, Julian Seward <js...@ac...> wrote: > > > Re your (1) .. (3), these might work, but function wrapping is already > complicated and fragile, especially for platforms which use TOC pointers, > and I really don't want to mess with it. > > Supposing it was possible to implement a data structure for which updates > and queries are atomic. This is easily enough done by putting the > structure > and its access functions in the drd tool code and adding some client > requests to modify/query it. > > The question is, is that sufficient? Or do you really need to be able > to run arbitrary sections of locked code in the wrappers? > > Could you give a short summary of what the data structure requirements > are and what the locking requirements are [in the wrappers]. I don't > yet feel like I have a good enough picture of that. > > J > > > > On Sunday 17 September 2006 14:03, Bart Van Assche wrote: > > A client request for querying the Valgrind ThreadId from within the > client > > is not sufficient, it is also necessary to have locking primitives > > available that work from within vg_preloaded.so. There are several > possible > > solutions: (1) Change macro's like VALGRIND_GET_ORIG_FN such that these > > also return the original function address when one function defined in > > vg_preloaded.so calls another function defined in vg_preloaded.so. > > (2) Make it possible to disable function wrapping, such that who > implements > > functions in vg_preloaded.so has the option of either calling the > > non-wrapped or the wrapped function. > > (3) Directly call alternative locking functions from within > > vg_preloaded.so, such as sys_futex(). > > > > Option (3) would make porting drd hard: e.g. sys_futex() is available on > > Linux, but not on AIX. > > Option (1) is the most elegant, but I don't know whether it is possible > to > > implement. > > Option (2) has the disadvantage that data-race detection will have to be > > explicitly disabled for the data structures accessed from > vg_preloaded.so. > > > > On 9/14/06, Julian Seward <js...@ac...> wrote: > > > Sounds plausible, and I like the idea of not messing with the state > > > machine. So you are saying, if you had a client request > > > VG_USERREQ__GET_MY_THREADID, that is all you would need? > > > > > > How would you do the locking for this data structure? Would you > > > use pthread_mutex_{lock,unlock}? Does anything break if you call > > > those from inside the wrappers for pthread_{create,join} ? > |
|
From: Julian S. <js...@ac...> - 2006-09-17 13:52:34
|
Re your (1) .. (3), these might work, but function wrapping is already
complicated and fragile, especially for platforms which use TOC pointers,
and I really don't want to mess with it.
Supposing it was possible to implement a data structure for which updates
and queries are atomic. This is easily enough done by putting the structure
and its access functions in the drd tool code and adding some client
requests to modify/query it.
The question is, is that sufficient? Or do you really need to be able
to run arbitrary sections of locked code in the wrappers?
Could you give a short summary of what the data structure requirements
are and what the locking requirements are [in the wrappers]. I don't
yet feel like I have a good enough picture of that.
J
On Sunday 17 September 2006 14:03, Bart Van Assche wrote:
> A client request for querying the Valgrind ThreadId from within the client
> is not sufficient, it is also necessary to have locking primitives
> available that work from within vg_preloaded.so. There are several possible
> solutions: (1) Change macro's like VALGRIND_GET_ORIG_FN such that these
> also return the original function address when one function defined in
> vg_preloaded.so calls another function defined in vg_preloaded.so.
> (2) Make it possible to disable function wrapping, such that who implements
> functions in vg_preloaded.so has the option of either calling the
> non-wrapped or the wrapped function.
> (3) Directly call alternative locking functions from within
> vg_preloaded.so, such as sys_futex().
>
> Option (3) would make porting drd hard: e.g. sys_futex() is available on
> Linux, but not on AIX.
> Option (1) is the most elegant, but I don't know whether it is possible to
> implement.
> Option (2) has the disadvantage that data-race detection will have to be
> explicitly disabled for the data structures accessed from vg_preloaded.so.
>
> On 9/14/06, Julian Seward <js...@ac...> wrote:
> > Sounds plausible, and I like the idea of not messing with the state
> > machine. So you are saying, if you had a client request
> > VG_USERREQ__GET_MY_THREADID, that is all you would need?
> >
> > How would you do the locking for this data structure? Would you
> > use pthread_mutex_{lock,unlock}? Does anything break if you call
> > those from inside the wrappers for pthread_{create,join} ?
|
|
From: Bart V. A. <bar...@gm...> - 2006-09-17 13:03:50
|
A client request for querying the Valgrind ThreadId from within the client
is not sufficient, it is also necessary to have locking primitives available
that work from within vg_preloaded.so. There are several possible solutions:
(1) Change macro's like VALGRIND_GET_ORIG_FN such that these also return the
original function address when one function defined in vg_preloaded.so calls
another function defined in vg_preloaded.so.
(2) Make it possible to disable function wrapping, such that who implements
functions in vg_preloaded.so has the option of either calling the
non-wrapped or the wrapped function.
(3) Directly call alternative locking functions from within vg_preloaded.so,
such as sys_futex().
Option (3) would make porting drd hard: e.g. sys_futex() is available on
Linux, but not on AIX.
Option (1) is the most elegant, but I don't know whether it is possible to
implement.
Option (2) has the disadvantage that data-race detection will have to be
explicitly disabled for the data structures accessed from vg_preloaded.so.
On 9/14/06, Julian Seward <js...@ac...> wrote:
>
>
> Sounds plausible, and I like the idea of not messing with the state
> machine. So you are saying, if you had a client request
> VG_USERREQ__GET_MY_THREADID, that is all you would need?
>
> How would you do the locking for this data structure? Would you
> use pthread_mutex_{lock,unlock}? Does anything break if you call
> those from inside the wrappers for pthread_{create,join} ?
>
|
|
From: <js...@ac...> - 2006-09-17 12:11:46
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-09-17 09:00:01 BST 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 == 207 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) 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-09-17 10:11:54
|
Author: sewardj
Date: 2006-09-17 11:11:51 +0100 (Sun, 17 Sep 2006)
New Revision: 6077
Log:
Update.
Modified:
trunk/docs/internals/3_2_BUGSTATUS.txt
Modified: trunk/docs/internals/3_2_BUGSTATUS.txt
=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/docs/internals/3_2_BUGSTATUS.txt 2006-09-17 09:50:15 UTC (rev 6=
076)
+++ trunk/docs/internals/3_2_BUGSTATUS.txt 2006-09-17 10:11:51 UTC (rev 6=
077)
@@ -13,12 +13,16 @@
pending pending 129390 ppc?->IR: some kind of VMX prefetch (dstt=
)
pending pending 129968 amd64->IR: 0xF 0xAE 0x0 (fxsave)
pending pending [W] 133054 'make install' fails with syntax errors
-Signal race condition (users list, 13 June, Johannes Berg)
-Unrecognised instruction at address 0x70198EC2 (users, 19 July, Bennee)
pending wontfix 133154 crash when using client requests to=20
register/deregister stack
pending pending 132998 startup fails in when running on UML
pending pending 133327 support for voicetronix ioctl (w/patch)
+pending pending 133679 Callgrind does not write path names to=20
+ sources with dwarf debug info
+pending pending 133962 amd64->IR: 0xF2 0x4C 0xF 0x10
+vx1660 pending n-i-bz %eflags rule for SUBL-CondNLE
+Signal race condition (users list, 13 June, Johannes Berg)
+Unrecognised instruction at address 0x70198EC2 (users, 19 July, Bennee)
=20
------- Bugs reported and fixed in 3.2.0 ------
=20
|
|
From: <sv...@va...> - 2006-09-17 10:02:39
|
Author: sewardj
Date: 2006-09-17 11:02:35 +0100 (Sun, 17 Sep 2006)
New Revision: 1660
Log:
Another day, another %eflags reduction rule.
Modified:
trunk/priv/guest-x86/ghelpers.c
Modified: trunk/priv/guest-x86/ghelpers.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/priv/guest-x86/ghelpers.c 2006-09-16 00:12:10 UTC (rev 1659)
+++ trunk/priv/guest-x86/ghelpers.c 2006-09-17 10:02:35 UTC (rev 1660)
@@ -853,6 +853,16 @@
binop(Iop_CmpLE32S, cc_dep1, cc_dep2));
}
=20
+ if (isU32(cc_op, X86G_CC_OP_SUBL) && isU32(cond, X86CondNLE)) {
+ /* long sub/cmp, then LE (signed not less than or equal)
+ --> test dst >s src=20
+ --> test !(dst <=3Ds src) */
+ return binop(Iop_Xor32,
+ unop(Iop_1Uto32,
+ binop(Iop_CmpLE32S, cc_dep1, cc_dep2)),
+ mkU32(1));
+ }
+
if (isU32(cc_op, X86G_CC_OP_SUBL) && isU32(cond, X86CondBE)) {
/* long sub/cmp, then BE (unsigned less than or equal)
--> test dst <=3Du src */
|
|
From: <sv...@va...> - 2006-09-17 09:50:21
|
Author: sewardj
Date: 2006-09-17 10:50:15 +0100 (Sun, 17 Sep 2006)
New Revision: 6076
Log:
Update following 3.2.1 release.
Modified:
trunk/docs/internals/3_2_BUGSTATUS.txt
Modified: trunk/docs/internals/3_2_BUGSTATUS.txt
=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/docs/internals/3_2_BUGSTATUS.txt 2006-09-16 01:09:58 UTC (rev 6=
075)
+++ trunk/docs/internals/3_2_BUGSTATUS.txt 2006-09-17 09:50:15 UTC (rev 6=
076)
@@ -7,8 +7,23 @@
[W] =3D waiting for feedback from bug reporter
Vfd =3D fix has been verified on 3.2.X branch
=20
-------- Bugs reported after (in) 3.2.0 ------
+------- Bugs reported after (in) 3.2.1, or ------
+------- reported in 3.2.0 but not fixed in 3.2.1 ------
=20
+pending pending 129390 ppc?->IR: some kind of VMX prefetch (dstt=
)
+pending pending 129968 amd64->IR: 0xF 0xAE 0x0 (fxsave)
+pending pending [W] 133054 'make install' fails with syntax errors
+Signal race condition (users list, 13 June, Johannes Berg)
+Unrecognised instruction at address 0x70198EC2 (users, 19 July, Bennee)
+pending wontfix 133154 crash when using client requests to=20
+ register/deregister stack
+pending pending 132998 startup fails in when running on UML
+pending pending 133327 support for voicetronix ioctl (w/patch)
+
+------- Bugs reported and fixed in 3.2.0 ------
+
+SSE3 commits: vx1635,1636, v5997
+
TRUNK 32BRANCH PRI BUG# WHAT
=20
v5974 v6013 n-i-bz Expanding brk() into last available page =
asserts
@@ -25,59 +40,34 @@
vx1643/v6032 128917 amd64->IR: 0x66 0xF 0xF6 0xC4 (psadbw,SSE=
2)
v5988 v6019 129246 JJ: ppc32/ppc64 syscalls, w/ patch
sse3fix vx1646 Vfd 129358 x86->IR: fisttpl (SSE3)
-pending pending 129390 ppc?->IR: some kind of VMX prefetch (dstt=
)
v6003,4 v6025 Vfd 129866 cachegrind/callgrind causes executable to=
die
-pending pending 129968 amd64->IR: 0xF 0xAE 0x0 (fxsave)
v5979 v6021 130020 Can't stat .so/.exe error while reading s=
ymbols
wontfix wontfix 130358 Inconsistent 80-bit floats on x86
v5983 v6022 130388 Valgrind aborts when process calls malloc=
_trim()
v5989 v6020 130638 PATCH: ppc32 missing system calls
vx1633 vx1644 130785 amd64->IR: unhandled instruction "pushfq"
-
vx1634 vx1645 131481: (HINT_NOP) vex x86->IR: 0xF 0x1F 0x0 0xF
131298 =3D=3D131481
-
vx1638 vx1648 Vfd 132146 Programs with long sequences of bswap[l,q=
]s
-
vx1655 vx1657 Vfd 132918 vex amd64->IR: 0xD9 0xF8 (fprem)
vx1652,3 vx1654 Vfd 132813 Assertion at priv/guest-x86/toIR.c:652 fa=
ils
v6040 v6041 133051 'cfsi->len > 0 && cfsi->len < 2000000' fa=
iled
-pending pending [W] 133054 'make install' fails with syntax errors
v6036 v6037 132722 valgrind header files are not standard C
-
v5990 v6023 n-i-bz Livelocks entire machine (users list,
17 June, Timothy B. Terriberry)
v5991,4,6 v6024 n-i-bz Graydon leak checking fix
-
v5992,6006 wontfix n-i-bz Graydon mempool trim patch
-
-Signal race condition (users list, 13 June, Johannes Berg)
-
-Unrecognised instruction at address 0x70198EC2 (users, 19 July, Bennee)
-
-SSE3 commits: vx1635,1636, v5997
-
v6001 v6026 n-i-bz Alex Bennee mmap problem (9 Aug)
v5999 v6027 n-i-bz BartV: Don't print more lines of a
stack-trace than were obtained.
v6010 v6028 n-i-bz ppc32 SuSE 10.1 redir
v6011 v6029 n-i-bz amd64 padding suppressions
-
vx1637 vx1647 n-i-bz amd64 insn printing fix.
vx1640,1 vx1650 n-i-bz ppc cmp reg,reg fix
vx1642 vx1651 n-i-bz x86/amd64 iropt e/rflag reduction rules
-
-pending wontfix 133154 crash when using client requests to=20
- register/deregister stack
-
v6051 v6048 n-i-bz SuSE 10.1 (ppc32) minor fixes
-
-pending pending 132998 startup fails in when running on UML
-pending pending 133327 support for voicetronix ioctl (w/patch)
-
vx1656 vx1658 Vfd 133678 amd64->IR: 0x48 0xF 0xC5 0xC0 (pextrw?)
v6049 v6054 Vfd 133694 aspacem assertion: aspacem_minAddr <=3D h=
oleStart
-
v6043 v6055 n-i-bz callgrind: fix warning about malformed
creator line=20
v6044 v6056 n-i-bz callgrind: fix annotate script for data=20
@@ -86,7 +76,5 @@
v6053 toggling instrumentation mode
v6064 v6067 n-i-bz callgrind_annotate: fix warnings with
"--collect-jumps=3Dyes"
-
v6059 v6060 n-i-bz docs path hardwired (Dennis Lubert)
-
v6068 v6066 n-i-bz Yet another X padding suppression
|
|
From: Tom H. <to...@co...> - 2006-09-17 02:46:28
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-17 03:30:06 BST 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 == 240 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/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-17 02:25:23
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-17 03:10:03 BST 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 == 268 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-17 02:24:54
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-17 03:15:02 BST 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/ccEDaVid.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEDaVid.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEDaVid.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEDaVid.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEDaVid.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEDaVid.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEDaVid.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEDaVid.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.3839/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.3839/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.3839/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.3839/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.3839/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/ccl9vLtk.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl9vLtk.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl9vLtk.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl9vLtk.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl9vLtk.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl9vLtk.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl9vLtk.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccl9vLtk.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.3839/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.3839/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.3839/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.3839/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.3839/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Sep 17 03:19:54 2006 --- new.short Sun Sep 17 03:24:50 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccl9vLtk.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl9vLtk.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl9vLtk.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl9vLtk.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl9vLtk.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl9vLtk.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl9vLtk.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccl9vLtk.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/ccEDaVid.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEDaVid.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEDaVid.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEDaVid.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEDaVid.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEDaVid.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEDaVid.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEDaVid.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-17 02:20:18
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-17 03:05:09 BST 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 == 268 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leakotron (stdout) 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) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-17 02:13:52
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-17 03:00:04 BST 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 == 270 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (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) |