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
(9) |
3
(11) |
4
(12) |
5
(11) |
|
6
(9) |
7
(13) |
8
(6) |
9
(7) |
10
(7) |
11
(11) |
12
(13) |
|
13
(7) |
14
(6) |
15
(7) |
16
(19) |
17
(20) |
18
(9) |
19
(9) |
|
20
(6) |
21
(7) |
22
(11) |
23
(16) |
24
(14) |
25
(24) |
26
(16) |
|
27
(20) |
28
(58) |
29
(7) |
30
(10) |
31
(15) |
|
|
|
From: Julian S. <js...@ac...> - 2006-08-25 22:44:29
|
> --29272-- Discarding ordered segments -- min vc is [ 1: 3214 ], max vc is [
> 1: 3214 ]
Progress. thread_append_segment() doesn't correctly update the
doubly-linked list of segments associated with a thread, which
causes thread_discard_ordered_segments() to fail to throw away
any segments. The ultra-minimal fix is to add
if (sg->prev != 0)
sg->prev->next = sg;
at the end of thread_append_segment(). With this, I can start
konq in about 1200M, which isn't great, but but it's a big
improvement on not being able to start it in 2600M.
Attached file drd_baseline_diffs.txt contains my complete diffs
vs valgrind-5999-drd-2006-08-14.tar.bz2, and includes this fix.
I also experimented with getting rid of the malloc/free intercepts,
which is done with the Makefile.am patch shown below (followed by
complete rebuild). This reduces konq's memory use to about 160M,
which is much more in line with what I would expect this tool to use.
So the next question is, why doe the malloc/free intercepting
cost ~940MB for konq? Bearing in mind memcheck and massif do
intercepting without a huge space overhead.
Bart: another thing (non-critical): -v makes drd crash for
drd/tests/fp_race:
Suppression requested for range [0xDAF2, 0xFF38038E[ while this has
already been requested for range [0x40161D0, 0x40161D4[.
drd: drd_suppression.c:66 (drd_start_suppression): the 'impossible'
happened.
J
diff -u -r ./ORIGINAL/drd/Makefile.am drd/Makefile.am
--- ./ORIGINAL/drd/Makefile.am 2006-08-14 14:40:44.000000000 +0100
+++ drd/Makefile.am 2006-08-25 23:24:07.000000000 +0100
@@ -2,19 +2,19 @@
noinst_PROGRAMS =
if VG_X86_LINUX
- noinst_PROGRAMS += drd-x86-linux vgpreload_drd-x86-linux.so
+ noinst_PROGRAMS += drd-x86-linux
PLATFORM = X86
endif
if VG_AMD64_LINUX
- noinst_PROGRAMS += drd-amd64-linux vgpreload_drd-amd64-linux.so
+ noinst_PROGRAMS += drd-amd64-linux
PLATFORM = AMD64
endif
if VG_PPC32_LINUX
- noinst_PROGRAMS += drd-ppc32-linux vgpreload_drd-ppc32-linux.so
+ noinst_PROGRAMS += drd-ppc32-linux
PLATFORM = PPC32
endif
if VG_PPC64_LINUX
-noinst_PROGRAMS += drd-ppc64-linux vgpreload_drd-ppc64-linux.so
+noinst_PROGRAMS += drd-ppc64-linux
endif
VGPRELOAD_DRD_SOURCES_COMMON =
|
|
From: Julian S. <js...@ac...> - 2006-08-25 21:11:07
|
> I've also noticed that bitmaps are never free'd, apparently because even > client free's never cause the associated client bits to be thrown away. For > the puprose of drd, I guess we have to assume that the application does not > have memory management errors, and therefore free should be able to discard > shadow allocations. > > overall this leads to every allocation causing two entire pages to be > allocated and never be free'd, which leads to quickly eating up all > available system ressources. Oh, that's really bad :-( Thanks for digging it up. So, indeed the problem is made a lot worse by the bitmaps and client data being interleaved in the address space. > I've tried the aspacemngr handling, but it only made it worse. Hmm, you mean using VG_(am_shadow_alloc) to grab the bitmaps? That's strange. I've just been playing around with this, but am getting confused. I can't get a konq startup below 2GB. > On the > bright side, I didn't have to implement freelist handling since free was > never called :) I think that's a clue :-) Ok. Question for Bart. Running with --trace-segment=yes gives a clue. I _think_ the problem is that drd is generating thousands of segments. konq is single threaded, but is doing pthread_mutex_lock/unlock and I believe this is creating segments, which AIUI is correct. Unfortunately it never throws any segments away (hence Dirk's observation that no bitmaps are ever freed). Instead I get this kind of thing --29272-- new bitmap at 0x71EBBC10 (4096 4096 1024) --29272-- New segment for thread 1 with vc [ 1: 3215 ] --29272-- new bitmap at 0x71EC1CE8 (4096 4096 1024) --29272-- New segment for thread 1 with vc [ 1: 3216 ] --29272-- new bitmap at 0x71EC7DC0 (4096 4096 1024) --29272-- New segment for thread 1 with vc [ 1: 3217 ] --29272-- new bitmap at 0x71ECE2A8 (4096 4096 1024) --29272-- New segment for thread 1 with vc [ 1: 3218 ] --29272-- new bitmap at 0x71ED90B0 (4096 4096 1024) --29272-- New segment for thread 1 with vc [ 1: 3219 ] --29272-- new bitmap at 0x71EDF598 (4096 4096 1024) --29272-- New segment for thread 1 with vc [ 1: 3220 ] --29272-- new bitmap at 0x71EE4250 (4096 4096 1024) --29272-- New segment for thread 1 with vc [ 1: 3221 ] --29272-- new bitmap at 0x71F0A278 (4096 4096 1024) --29272-- New segment for thread 1 with vc [ 1: 3222 ] --29272-- new bitmap at 0x71F0EF30 (4096 4096 1024) --29272-- New segment for thread 1 with vc [ 1: 3223 ] --29272-- new bitmap at 0x71F15008 (4096 4096 1024) and every 16 new segments, thread_discard_ordered_segments tries to dump old segments, but I guess it fails: --29272-- Discarding ordered segments -- min vc is [ 1: 3214 ], max vc is [ 1: 3214 ] Not sure what's going on (I don't understand this vector clock stuff hardly at all). Is it right that thread_discard_ordered_segments always computes min and max vc's to be the same? J |
|
From: Dirk M. <dm...@gm...> - 2006-08-25 13:27:47
|
On Friday 25 August 2006 13:19, Julian Seward wrote: > Having looked a bit at drd's bitmap code, it looks OK. I have the > impression that the leaking is caused by some higher-level issues > about when/how bitmaps can be discarded, and when not. I suspect it's > probably not hard to track down, but looks like nobody has time to > chase it right now. I've looked further. whenever the application does some new or new[] call, an extra bitmap is allocated, which, due to its size, causes the next new or new[] call to again allocate a new page instead of being merged into the previously allocated block. I've tried to remove the malloc wrapping but that didn't work. I've also noticed that bitmaps are never free'd, apparently because even client free's never cause the associated client bits to be thrown away. For the puprose of drd, I guess we have to assume that the application does not have memory management errors, and therefore free should be able to discard shadow allocations. overall this leads to every allocation causing two entire pages to be allocated and never be free'd, which leads to quickly eating up all available system ressources. I've tried the aspacemngr handling, but it only made it worse. On the bright side, I didn't have to implement freelist handling since free was never called :) Dirk |
|
From: Bart V. A. <bar...@gm...> - 2006-08-25 13:10:17
|
Hello Julian,
I tried to run "make perf", but got the following error messages:
if gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -Winline -Wall -O -mregnames
-DHAS_
ALTIVEC -maltivec -m32 -Wno-long-long -Wdeclaration-after-statement -MT
jm_insns
-jm-insns.o -MD -MP -MF ".deps/jm_insns-jm-insns.Tpo" -c -o jm_insns-
jm-insns.o
`test -f 'jm-insns.c' || echo './'`jm-insns.c; \
then mv -f ".deps/jm_insns-jm-insns.Tpo" ".deps/jm_insns-jm-insns.Po"; else
rm -
f ".deps/jm_insns-jm-insns.Tpo"; exit 1; fi
In file included from jm-insns.c:192:
/usr/lib/gcc/powerpc-montavista-linux/3.4.3/include/altivec.h:36:2: #error
Use t
he "-maltivec" flag to enable PowerPC AltiVec support
jm-insns.c:377: error: parse error before "unsigned"
jm-insns.c:4119: error: syntax error before "unsigned"
jm-insns.c:4121: error: syntax error before "float"
jm-insns.c: In function `build_viargs_table':
jm-insns.c:4365: error: `__vector' undeclared (first use in this function)
On 8/25/06, Julian Seward <js...@ac...> wrote:
>
>
> Bart
>
> The ppc32-linux port is one of the most efficient, and has performance
> characteristics similar to x86-linux. Running on an MPC7447A
> (1250 MHz Freescale CPU in a Mac Mini) it consistently shows amongst
> the lowest slowdowns I have seen.
>
> Performance of V depends on many facets, and it's impossible to tell
> from your bash run what the problem might be. It would be better to
> run the performance test suite ("make perf" at the top level) and
> report the results of that for both platforms. At least for the few
> programs in that suite we have some idea of what parts of the
> system they stress.
>
|
|
From: <sv...@va...> - 2006-08-25 13:07:33
|
Author: sewardj
Date: 2006-08-25 14:07:30 +0100 (Fri, 25 Aug 2006)
New Revision: 6012
Log:
Add missing #include.
Modified:
trunk/none/tests/bug129866.c
Modified: trunk/none/tests/bug129866.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/none/tests/bug129866.c 2006-08-25 12:53:32 UTC (rev 6011)
+++ trunk/none/tests/bug129866.c 2006-08-25 13:07:30 UTC (rev 6012)
@@ -1,5 +1,7 @@
=20
#include <stdlib.h>
+#include <stdio.h>
+
char * touch_malloc (int size)=20
{
char * result;
|
|
From: <sv...@va...> - 2006-08-25 12:53:35
|
Author: sewardj
Date: 2006-08-25 13:53:32 +0100 (Fri, 25 Aug 2006)
New Revision: 6011
Log:
Suppressions for various structure padding things on amd64 SuSE 10.1.
Modified:
trunk/glibc-2.4.supp
Modified: trunk/glibc-2.4.supp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/glibc-2.4.supp 2006-08-25 11:48:38 UTC (rev 6010)
+++ trunk/glibc-2.4.supp 2006-08-25 12:53:32 UTC (rev 6011)
@@ -124,3 +124,114 @@
fun:index
fun:expand_dynamic_string_token
}
+
+
+##----------------------------------------------------------------------=
##
+## Various structure padding things on amd64 SuSE 10.1
+##
+{
+ X11-64bit-padding-1a
+ Memcheck:Param
+ write(buf)
+ fun:__write_nocancel
+ obj:/usr/X*/libX11.so*
+ obj:/usr/X*/libX11.so*
+ fun:X*
+}
+{
+ X11-64bit-padding-1b
+ Memcheck:Param
+ write(buf)
+ fun:__write_nocancel
+ obj:/usr/X*/libX11.so*
+ obj:/usr/X*/libX11.so*
+ fun:_X*
+}
+{
+ X11-64bit-padding-1c
+ Memcheck:Param
+ write(buf)
+ fun:__write_nocancel
+ obj:/usr/X*/libX11.so*
+ obj:/usr/X*/libX11.so*
+ obj:/usr/X*/libX11.so*
+}
+{
+ X11-64bit-padding-1d
+ Memcheck:Param
+ write(buf)
+ fun:__write_nocancel
+ obj:/usr/X*/libICE.so*
+ obj:/usr/X*/libICE.so*
+ obj:/usr/X*/libICE.so*
+}
+
+
+{
+ X11-64bit-padding-2a
+ Memcheck:Param
+ writev(vector[...])
+ fun:do_writev
+ obj:/usr/X*/libX11.so*
+ obj:/usr/X*/libX11.so*
+ obj:/usr/X*/libX11.so*
+}
+{
+ X11-64bit-padding-2b
+ Memcheck:Param
+ writev(vector[...])
+ fun:do_writev
+ fun:writev
+ obj:/usr/X*/libX11.so*
+ obj:/usr/X*/libX11.so*
+}
+
+{
+ glibc24-64bit-padding-1a
+ Memcheck:Param
+ socketcall.sendto(msg)
+ fun:send
+ fun:get_mapping
+ fun:__nscd_get_map_ref
+ fun:nscd*
+}
+{
+ glibc24-64bit-padding-1b
+ Memcheck:Param
+ socketcall.sendto(msg)
+ fun:__sendto_nocancel
+ obj:/*libc-2.4.so
+ obj:/*libc-2.4.so
+ obj:/*libc-2.4.so
+}
+{
+ glibc24-64bit-padding-1c
+ Memcheck:Param
+ socketcall.send(msg)
+ fun:send
+ fun:__nscd_get_map_ref
+ fun:nscd_get*_r
+ fun:*nscd*
+ obj:/*libc-2.4.so
+}
+
+
+{
+ X11-64bit-padding-3a
+ Memcheck:Param
+ write(buf)
+ obj:/*libpthread-2.4.so*
+ obj:/usr/X*/libX11.so*
+ obj:/usr/X*/libX11.so*
+ obj:/usr/X*/libX11.so*
+}
+
+{
+ X11-64bit-padding-4a
+ Memcheck:Param
+ socketcall.sendto(msg)
+ fun:send
+ obj:/*libc-2.4.so
+ obj:/*libc-2.4.so
+ obj:/*libc-2.4.so
+}
|
|
From: <sv...@va...> - 2006-08-25 12:52:29
|
Author: sewardj
Date: 2006-08-25 13:52:19 +0100 (Fri, 25 Aug 2006)
New Revision: 1642
Log:
More reduction rules, which further reduce memcheck's false error
rate on optimised x86 and amd64 code.
Modified:
trunk/priv/guest-amd64/ghelpers.c
trunk/priv/guest-x86/ghelpers.c
Modified: trunk/priv/guest-amd64/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-amd64/ghelpers.c 2006-08-19 22:18:53 UTC (rev 1641)
+++ trunk/priv/guest-amd64/ghelpers.c 2006-08-25 12:52:19 UTC (rev 1642)
@@ -958,12 +958,6 @@
binop(Iop_Shl64,cc_dep2,mkU8(32))));
}
=20
-//.. if (isU32(cc_op, AMD64G_CC_OP_SUBL) && isU32(cond, X86CondNZ)=
) {
-//.. /* long sub/cmp, then NZ --> test dst!=3Dsrc */
-//.. return unop(Iop_1Uto32,
-//.. binop(Iop_CmpNE32, cc_dep1, cc_dep2));
-//.. }
-
if (isU64(cc_op, AMD64G_CC_OP_SUBL) && isU64(cond, AMD64CondL)) {
/* long sub/cmp, then L (signed less than)=20
--> test dst <s src */
@@ -992,12 +986,15 @@
binop(Iop_Shl64,cc_dep2,mkU8(32))));
}
=20
-//.. if (isU32(cc_op, AMD64G_CC_OP_SUBL) && isU32(cond, X86CondB))=
{
-//.. /* long sub/cmp, then B (unsigned less than)
-//.. --> test dst <u src */
-//.. return unop(Iop_1Uto32,
-//.. binop(Iop_CmpLT32U, cc_dep1, cc_dep2));
-//.. }
+ if (isU64(cc_op, AMD64G_CC_OP_SUBL) && isU64(cond, AMD64CondNBE)) =
{
+ /* long sub/cmp, then NBE (unsigned greater than)
+ --> test src <u dst */
+ /* Note, args are opposite way round from the usual */
+ return unop(Iop_1Uto64,
+ binop(Iop_CmpLT64U,=20
+ binop(Iop_Shl64,cc_dep2,mkU8(32)),
+ binop(Iop_Shl64,cc_dep1,mkU8(32))));
+ }
=20
/*---------------- SUBW ----------------*/
=20
@@ -1029,6 +1026,14 @@
unop(Iop_64to8,cc_dep2)));
}
=20
+ if (isU64(cc_op, AMD64G_CC_OP_SUBB) && isU64(cond, AMD64CondNZ)) {
+ /* byte sub/cmp, then NZ --> test dst!=3Dsrc */
+ return unop(Iop_1Uto64,
+ binop(Iop_CmpNE8,=20
+ unop(Iop_64to8,cc_dep1),
+ unop(Iop_64to8,cc_dep2)));
+ }
+
if (isU64(cc_op, AMD64G_CC_OP_SUBB) && isU64(cond, AMD64CondS)
&& isU64(cc_dep2, 0)) {
/* byte sub/cmp of zero, then S --> test (dst-0 <s 0)
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-08-19 22:18:53 UTC (rev 1641)
+++ trunk/priv/guest-x86/ghelpers.c 2006-08-25 12:52:19 UTC (rev 1642)
@@ -1056,6 +1056,16 @@
return unop(Iop_1Uto32,binop(Iop_CmpLT32S, cc_dep1, mkU32(0)));
}
=20
+ /*---------------- DECW ----------------*/
+
+ if (isU32(cc_op, X86G_CC_OP_DECW) && isU32(cond, X86CondZ)) {
+ /* dec W, then Z --> test dst =3D=3D 0 */
+ return unop(Iop_1Uto32,
+ binop(Iop_CmpEQ32,=20
+ binop(Iop_Shl32,cc_dep1,mkU8(16)),=20
+ mkU32(0)));
+ }
+
/*---------------- INCW ----------------*/
=20
if (isU32(cc_op, X86G_CC_OP_INCW) && isU32(cond, X86CondZ)) {
|
|
From: <sv...@va...> - 2006-08-25 11:48:44
|
Author: sewardj
Date: 2006-08-25 12:48:38 +0100 (Fri, 25 Aug 2006)
New Revision: 6010
Log:
SuSE 10.1 (ppc32/64) fixlet.
Modified:
trunk/coregrind/m_redir.c
Modified: trunk/coregrind/m_redir.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/coregrind/m_redir.c 2006-08-23 08:27:03 UTC (rev 6009)
+++ trunk/coregrind/m_redir.c 2006-08-25 11:48:38 UTC (rev 6010)
@@ -762,6 +762,10 @@
"ld.so.1", "strcmp",
(Addr)&VG_(ppc32_linux_REDIR_FOR_strcmp)
);
+ add_hardwired_spec(
+ "ld.so.1", "index",
+ (Addr)&VG_(ppc32_linux_REDIR_FOR_strchr)
+ );
}
=20
# elif defined(VGP_ppc64_linux)
|
|
From: Julian S. <js...@ac...> - 2006-08-25 11:19:58
|
> > How reusable is the compressed bitmap stuff done for memcheck? can we > > reuse it here? > > I doubt it. The compressed V bits stuff in Memcheck is very > Memcheck-specific. Having looked a bit at drd's bitmap code, it looks OK. I have the impression that the leaking is caused by some higher-level issues about when/how bitmaps can be discarded, and when not. I suspect it's probably not hard to track down, but looks like nobody has time to chase it right now. J |
|
From: Nicholas N. <nj...@cs...> - 2006-08-25 10:46:53
|
On Wed, 23 Aug 2006, Dirk Mueller wrote: >> Or I am wrong and the drd tool is not storing read/write accesses for >> konqueror, but only the 500627 (*) mallocs with stack traces for potential >> later error messages. > > I've commented out that part, but it still OOMs quickly. My guess is that > there is some simple error in the bitmap'ing. > > How reusable is the compressed bitmap stuff done for memcheck? can we reuse it > here? I doubt it. The compressed V bits stuff in Memcheck is very Memcheck-specific. Nick |
|
From: <js...@ac...> - 2006-08-25 10:34:10
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-08-25 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: Julian S. <js...@ac...> - 2006-08-25 10:24:18
|
> > The SfMayBlock case is the general case and always safe. The
> > shortcut just-do-the-syscall-directly version is an optimisation used
> > for syscalls we're sure won't block and for which (get getpid) the
> > overhead of messing with signal masks etc is a bit silly.
> >
> > You unfortunately need to implement the general case (eventually);
> > but to get started you could just hardwire the syswrap-main logic to
> > use the shortcut scheme for now.
>
> FWIW, I finally got this sorted out today. I've got async mode syscalls
> working at last. You don't want to know what unspeakable evil I had to
> do in the machine dependent code.
Well actually .. will need to at some point.
> I'm familiar with that kind program counter magic - I've done similar
> things in the FreeBSD kernel before.
>
> I've got signals about 90% working now too, if only I can track down
> what the heck I've done to corrupt the stack with sigreturn(). The
> last 10% is probably going to cause more hair loss though.
There's a bunch of weird crap to do with the fake sigreturn syscall,
which I finally understood whilst hacking on AIX recently. I plan to
clean it up at some point. If you look at PRE(sys_sigreturn) in
syswrap-x86-linux.c (or any equivalent one) there is this:
/* For unclear reasons, it appears we need the syscall to return
without changing %EAX. Since %EAX is the return value, and can
denote either success or failure, we must set up so that the
driver logic copies it back unchanged. Also, note %EAX is of
the guest registers written by VG_(sigframe_destroy). */
SET_STATUS_from_SysRes( VG_(mk_SysRes_x86_linux)(
tst->arch.vex.guest_EAX ) );
Now I understand it. sys_sigreturn is really just a way to get V to
copy the thread's register state out of the signal frame and back into
the simulated registers (and remove the signal frame) as the kernel would
do when a sighandler returns.
In particular it's not a real system call and we don't want to 'return'
any value to user space. But the generic system call marshalling code
doesn't have the notion of a system call which doesn't return a value.
Hence the SET_STATUS_from_SysRes( VG_(mk_SysRes_x86_linux)(
tst->arch.vex.guest_EAX ) );
The idea is to cook up a fake return value for the syscall, which,
when put back into EAX (which is what the syscall driver will do)
leaves EAX unchanged. Sucky, huh?! It would be better to add an
SfNoWriteback flag.
Anyway, for FreeBSD you will have to do similar: cook up a SysRes
for sys_sigreturn which, when written back, does not change the
register state. That might be the cause of the corruption.
> FreeBSD has no sa_restorer field in its sigact records. I haven't
> figured out why Linux needs this on non-ppc64 yet, so I don't yet know
> if I'm in trouble or not. It looks like it isn't going to be a problem
> though.
I have no idea what it's for; ppc64-linux works perfectly well without
it. Perhaps PaulM knows?
J
|
|
From: Julian S. <js...@ac...> - 2006-08-25 10:13:28
|
---------- Forwarded Message ---------- Subject: Re: FYI: Valgrind 3.2 port to FreeBSD Date: Thursday 24 August 2006 04:24 From: Peter Wemm <pe...@we...> To: Julian Seward <js...@ac...> Cc: Nicholas Nethercote <nj...@cs...> On Wednesday 21 June 2006 19:20, Julian Seward wrote: [..] > > SfMayBlock [...] > > I guess I better explain this .. > > Because V only ever allows one thread to run at once, we need to be > careful when doing syscalls on behalf of the client. Suppose a > thread wants to do something harmless like getpid(); we can safely > just do a getpid and hand the result to the client. This is what > happens if SfMayBlock is not set; you can follow the logic in > syswrap-main.c. > > However, if we're doing something which might block, like read(), > then more care is needed. The assembly helper is then necessary. > It changes the host's signal mask to the guest signal mask, drops > the big lock which serialises the threads, and does the syscall. If > it should block that's fine, some other thread can now run. > Basically all the screwing around with what-the-program-counter-is > (which is very complex, took me ages to understand, this is Jeremy > Fitzhardinge's magic) deals with the case where, as a result of > switching signal masks, a signal is now delivered. > > The SfMayBlock case is the general case and always safe. The > shortcut just-do-the-syscall-directly version is an optimisation used > for syscalls we're sure won't block and for which (get getpid) the > overhead of messing with signal masks etc is a bit silly. > > You unfortunately need to implement the general case (eventually); > but to get started you could just hardwire the syswrap-main logic to > use the shortcut scheme for now. FWIW, I finally got this sorted out today. I've got async mode syscalls working at last. You don't want to know what unspeakable evil I had to do in the machine dependent code. I'm familiar with that kind program counter magic - I've done similar things in the FreeBSD kernel before. I've got signals about 90% working now too, if only I can track down what the heck I've done to corrupt the stack with sigreturn(). The last 10% is probably going to cause more hair loss though. FreeBSD has no sa_restorer field in its sigact records. I haven't figured out why Linux needs this on non-ppc64 yet, so I don't yet know if I'm in trouble or not. It looks like it isn't going to be a problem though. -- Peter Wemm - pe...@we...; peter@FreeBSD.org; pe...@ya... "All of this is for nothing if we don't go to the stars" - JMS/B5 ------------------------------------------------------- |
|
From: Julian S. <js...@ac...> - 2006-08-25 10:13:19
|
---------- Forwarded Message ----------
Subject: Re: FYI: Valgrind 3.2 port to FreeBSD
Date: Tuesday 22 August 2006 08:08
From: Peter Wemm <pe...@we...>
To: Julian Seward <js...@ac...>
Cc: Nicholas Nethercote <nj...@cs...>
> On Tuesday 15 August 2006 22:59, Peter Wemm wrote:
> > Progress update:
>
> Cool!
>
> > up in the last email yet. But I thought a FYI might be in order.
>
> Indeed; good to see progress.
>
> > My most recent "problem" was aspacemgr.c:get_name_from_fd() and
> > resolve_filename() in m_libcfile.c. We have no /proc/self/fd/<nn>
> > or equivalent. I didn't want to deal with adding code to track
> > names associated with fd's so I cheated and used a kernel module to
> > extract the current pathnames. It is a hack of the worst kind, but
> > I don't want to deal with it right now. I think we might add the
> > functionality to FreeBSD and use the kernel modules for older
> > releases.
>
> Do you need to know these names? What happens if you just produce
> fake strings with no useful info? I'm moderately sure m_aspacemgr
> doesn't really care what files are called - that's just for being
> pretty for the user's benefit.
The main consumer appears to be the debuginfo code for doing stack
traces. The /proc/curproc/map file on FreeBSD 4.x does not have a
filename (5.x+ does, like linux). With neither of Linux's methods
available, stack traces are reported in plain hex. When at least one
method is added we get function name and filename mappings with the
stack traces. I'm a little puzzled though, because there seem to be
places where filenames are tracked internally within Valgrind. Perhaps
only with --track-fds enabled or something? I haven't gone looking too
far yet - there is plenty more low hanging fruit to deal with yet.
> > BTW: the above traces appear to be real. valgrind 2.2 also
> > complains about the same problem, in spite of the protests from the
> > author of the code in question that it isn't possible...
>
> There are various classes of false errors that tend to happen,
> especially in libcs, and especially when bringing the system up on
> new platforms. Let me know if you want help chasing this down.
FreeBSD's libc doesn't have the __libc_freeres() infrastructure either.
That makes for a noisy report if you let Valgrind show you the
allocated-but-referenced memory left over by libc. Rather noisy in
fact. :)
My main plan is to get the core infrastructure working. I've got many
offers of help within the FreeBSD group to share the workload of grunt
work like verifying the syscall wrappers etc so I've been more focusing
on getting something running so that I can distribute my work a bit.
Signals are the last big phase-1 item - I'm fighting with them now.
They are winning so far..
Oh.. this might amuse you. FreeBSD's siginfo definitions lie. si_code
is #defined similarly as on Linux, but the actual codes that the kernel
generates are directly mapped from the initial trap numbers and have
absolutely no bearing on what is in the system include files (!!).
eg: the headers say:
/* codes for SIGSEGV */
#define SEGV_MAPERR 1 /* Address not mapped to object. */
#define SEGV_ACCERR 2 /* Invalid permissions for mapped */
/* object. */
BUT.. the kernel uses T_PAGEFLT (12) to indicate a page fault and
neither of the two listed values.
Sigh. I'm lost for words.
What's worse is that I know that some applications use this..
> J
--
Peter Wemm - pe...@we...; peter@FreeBSD.org; pe...@ya...
"All of this is for nothing if we don't go to the stars" - JMS/B5
-------------------------------------------------------
|
|
From: Julian S. <js...@ac...> - 2006-08-25 10:13:15
|
---------- Forwarded Message ---------- Subject: Re: FYI: Valgrind 3.2 port to FreeBSD Date: Friday 18 August 2006 10:41 From: Julian Seward <js...@ac...> To: Peter Wemm <pe...@we...> Cc: Nicholas Nethercote <nj...@cs...> On Tuesday 15 August 2006 22:59, Peter Wemm wrote: > Progress update: Cool! > up in the last email yet. But I thought a FYI might be in order. Indeed; good to see progress. > My most recent "problem" was aspacemgr.c:get_name_from_fd() and > resolve_filename() in m_libcfile.c. We have no /proc/self/fd/<nn> > or equivalent. I didn't want to deal with adding code to track names > associated with fd's so I cheated and used a kernel module to extract > the current pathnames. It is a hack of the worst kind, but I don't > want to deal with it right now. I think we might add the > functionality to FreeBSD and use the kernel modules for older releases. Do you need to know these names? What happens if you just produce fake strings with no useful info? I'm moderately sure m_aspacemgr doesn't really care what files are called - that's just for being pretty for the user's benefit. > BTW: the above traces appear to be real. valgrind 2.2 also complains > about the same problem, in spite of the protests from the author of the > code in question that it isn't possible... There are various classes of false errors that tend to happen, especially in libcs, and especially when bringing the system up on new platforms. Let me know if you want help chasing this down. J ------------------------------------------------------- |
|
From: Julian S. <js...@ac...> - 2006-08-25 10:13:01
|
---------- Forwarded Message ---------- Subject: Re: FYI: Valgrind 3.2 port to FreeBSD Date: Tuesday 15 August 2006 22:59 From: Peter Wemm <pe...@we...> To: Julian Seward <js...@ac...> Cc: Nicholas Nethercote <nj...@cs...> Progress update: peter@jt2[2:47pm]~/getpath-123> /home/peter/vginst/bin/valgrind /bin/ls ==74318== Memcheck, a memory error detector. ==74318== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==74318== Using LibVEX rev 1607, a library for dynamic binary translation. ==74318== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==74318== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==74318== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==74318== For more details, rerun with: -v ==74318== ==74318== Conditional jump or move depends on uninitialised value(s) ==74318== at 0x102F4B6: ??? (/home/src/lib/libc/../libc/stdlib/malloc.c:675) ==74318== by 0x102F574: ??? (/home/src/lib/libc/../libc/stdlib/malloc.c:717) ==74318== by 0x102FE1C: realloc (/home/src/lib/libc/../libc/stdlib/malloc.c:1130) ==74318== by 0x102BC43: reallocf (/home/src/lib/libc/../libc/stdlib/reallocf.c:35) ==74318== by 0x100F36B: ??? (/home/src/lib/libc/../libc/gen/fts.c:1020) ==74318== by 0x100E2EF: fts_open (/home/src/lib/libc/../libc/gen/fts.c:117) ==74318== by 0x1000B4A: traverse (/home/src/bin/ls/ls.c:434) ==74318== by 0x1000B0B: main (/home/src/bin/ls/ls.c:415) ==74318== ==74318== Conditional jump or move depends on uninitialised value(s) ==74318== at 0x102F4DD: ??? (/home/src/lib/libc/../libc/stdlib/malloc.c:688) ==74318== by 0x102F574: ??? (/home/src/lib/libc/../libc/stdlib/malloc.c:717) ==74318== by 0x102FE1C: realloc (/home/src/lib/libc/../libc/stdlib/malloc.c:1130) ==74318== by 0x102BC43: reallocf (/home/src/lib/libc/../libc/stdlib/reallocf.c:35) ==74318== by 0x100F36B: ??? (/home/src/lib/libc/../libc/gen/fts.c:1020) ==74318== by 0x100E2EF: fts_open (/home/src/lib/libc/../libc/gen/fts.c:117) ==74318== by 0x1000B4A: traverse (/home/src/bin/ls/ls.c:434) ==74318== by 0x1000B0B: main (/home/src/bin/ls/ls.c:415) ==74318== ==74318== Conditional jump or move depends on uninitialised value(s) ==74318== at 0x1021DDA: readdir (/home/src/lib/libc/../libc/gen/readdir.c:60) ==74318== by 0x100EEC1: ??? (/home/src/lib/libc/../libc/gen/fts.c:680) ==74318== by 0x100EAB7: fts_children (/home/src/lib/libc/../libc/gen/fts.c:544) ==74318== by 0x1000CCC: traverse (/home/src/bin/ls/ls.c:477) ==74318== by 0x1000B0B: main (/home/src/bin/ls/ls.c:415) Makefile getpath_fromfd.c obj t.c getpath_fromaddr.c ktrace.out t ==74318== ==74318== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) ==74318== malloc/free: in use at exit: 0 bytes in 0 blocks. ==74318== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==74318== For counts of detected errors, rerun with: -v ==74318== All heap blocks were freed -- no leaks are possible. peter@jt2[2:47pm]~/getpath-124> I've still got a mountain of things to do, but it's getting there. I haven't finished going through and dealing with the things you brought up in the last email yet. But I thought a FYI might be in order. My most recent "problem" was aspacemgr.c:get_name_from_fd() and resolve_filename() in m_libcfile.c. We have no /proc/self/fd/<nn> or equivalent. I didn't want to deal with adding code to track names associated with fd's so I cheated and used a kernel module to extract the current pathnames. It is a hack of the worst kind, but I don't want to deal with it right now. I think we might add the functionality to FreeBSD and use the kernel modules for older releases. BTW: the above traces appear to be real. valgrind 2.2 also complains about the same problem, in spite of the protests from the author of the code in question that it isn't possible... -- Peter Wemm - pe...@we...; peter@FreeBSD.org; pe...@ya... "All of this is for nothing if we don't go to the stars" - JMS/B5 ------------------------------------------------------- |
|
From: Julian S. <js...@ac...> - 2006-08-25 09:56:04
|
Bart
The ppc32-linux port is one of the most efficient, and has performance
characteristics similar to x86-linux. Running on an MPC7447A
(1250 MHz Freescale CPU in a Mac Mini) it consistently shows amongst
the lowest slowdowns I have seen.
Performance of V depends on many facets, and it's impossible to tell
from your bash run what the problem might be. It would be better to
run the performance test suite ("make perf" at the top level) and
report the results of that for both platforms. At least for the few
programs in that suite we have some idea of what parts of the
system they stress.
J
On Friday 25 August 2006 09:47, Bart Van Assche wrote:
> Update: I have performed two additional tests:
> (3) time valgrind --tool=none bash -c 'for ((i=0;i<5000;i++)); do echo -n
> "$i "; done'
> (4) time valgrind --tool=memcheck bash -c 'for ((i=0;i<5000;i++)); do echo
> -n "$i "; done'
>
> Resulting execution times on the x86 platform: 6.2s for test (3) and 16s
> for test (4).
> Resulting execution times on the ppc32 platform: 13s for test (3) and 40s
> for test (4).
>
> Or: test (4) runs 12 times slower than test (1) on x86, and 22 times on
> ppc32. There is still a significant difference between x86 and ppc32, but I
> think this difference (less than a factor two) is acceptable ? Now I'm
> wondering whether the large slowdown of test (2) is due to valgrind's
> --trace-children or due to the MVL kernel ? Would someone be so kind to
> repeat tests (1) and (2) on a ppc32 system running a vanilla Linux kernel ?
>
> ---------- Forwarded message ----------
> From: Bart Van Assche <bar...@gm...>
> Date: Aug 24, 2006 2:38 PM
> Subject: Performance issue in Valgrind's memcheck tool on the ppc32
> platform ?
> To: val...@li...
>
> Hello,
>
> I ran the following tests:
> (1) time bash -c 'for ((i=0;i<5000;i++)); do echo -n "$i "; done'
> (2) valgrind --trace-children=yes time bash -c 'for ((i=0;i<5000;i++)); do
> echo -n "$i "; done'
>
> on the following two platforms:
> (1) OpenSuSE 10.1 running on VMWare on a 2.8 GHz Pentium IV CPU, with
> Valgrind 3.1.1 (V installed locally)
> (2) MontaVista Linux Professional 4.0.1 running on a 800 MHz PowerPC 440GX
> CPU, with Valgrind 3.2.0 (V started over NFS)
>
> Resulting execution times on the x86 platform: 1.06s for test (1) and
> 16.6sfor test (2), or a slowdown of about 16 times.
> Resulting execution times on the ppc32 platform: 1.8s for test (1) and 400s
> for test (2), or a slowdown of about 222 times.
>
> Why is the slowdown of Valgrind on the ppc32 platform I tested so much
> larger (more than ten times !) than on the x86 platform ?
> Should I do more tests -- e.g. with another Valgrind version ?
|
|
From: Bart V. A. <bar...@gm...> - 2006-08-25 08:47:31
|
Update: I have performed two additional tests: (3) time valgrind --tool=none bash -c 'for ((i=0;i<5000;i++)); do echo -n "$i "; done' (4) time valgrind --tool=memcheck bash -c 'for ((i=0;i<5000;i++)); do echo -n "$i "; done' Resulting execution times on the x86 platform: 6.2s for test (3) and 16s for test (4). Resulting execution times on the ppc32 platform: 13s for test (3) and 40s for test (4). Or: test (4) runs 12 times slower than test (1) on x86, and 22 times on ppc32. There is still a significant difference between x86 and ppc32, but I think this difference (less than a factor two) is acceptable ? Now I'm wondering whether the large slowdown of test (2) is due to valgrind's --trace-children or due to the MVL kernel ? Would someone be so kind to repeat tests (1) and (2) on a ppc32 system running a vanilla Linux kernel ? ---------- Forwarded message ---------- From: Bart Van Assche <bar...@gm...> Date: Aug 24, 2006 2:38 PM Subject: Performance issue in Valgrind's memcheck tool on the ppc32 platform ? To: val...@li... Hello, I ran the following tests: (1) time bash -c 'for ((i=0;i<5000;i++)); do echo -n "$i "; done' (2) valgrind --trace-children=yes time bash -c 'for ((i=0;i<5000;i++)); do echo -n "$i "; done' on the following two platforms: (1) OpenSuSE 10.1 running on VMWare on a 2.8 GHz Pentium IV CPU, with Valgrind 3.1.1 (V installed locally) (2) MontaVista Linux Professional 4.0.1 running on a 800 MHz PowerPC 440GX CPU, with Valgrind 3.2.0 (V started over NFS) Resulting execution times on the x86 platform: 1.06s for test (1) and 16.6sfor test (2), or a slowdown of about 16 times. Resulting execution times on the ppc32 platform: 1.8s for test (1) and 400s for test (2), or a slowdown of about 222 times. Why is the slowdown of Valgrind on the ppc32 platform I tested so much larger (more than ten times !) than on the x86 platform ? Should I do more tests -- e.g. with another Valgrind version ? |
|
From: <js...@ac...> - 2006-08-25 05:05:21
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-08-25 03:30:01 BST 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 == 236 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (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-08-25 03:22:06
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-08-25 03:00:05 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 == 266 tests, 6 stderr failures, 2 stdout failures, 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) none/tests/tls (stdout) |
|
From: Tom H. <to...@co...> - 2006-08-25 02:46:07
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-08-25 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 == 238 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-08-25 02:25:17
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-08-25 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 == 264 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-08-25 02:24:47
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-08-25 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/ccvtafC0.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccvtafC0.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccvtafC0.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccvtafC0.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccvtafC0.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccvtafC0.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccvtafC0.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccvtafC0.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.12417/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.12417/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.12417/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.12417/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.12417/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/ccOihubF.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOihubF.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOihubF.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOihubF.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOihubF.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOihubF.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOihubF.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOihubF.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.12417/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.12417/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.12417/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.12417/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.12417/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Aug 25 03:19:50 2006 --- new.short Fri Aug 25 03:24:36 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccOihubF.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOihubF.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOihubF.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOihubF.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOihubF.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOihubF.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOihubF.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOihubF.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/ccvtafC0.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccvtafC0.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccvtafC0.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccvtafC0.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccvtafC0.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccvtafC0.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccvtafC0.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccvtafC0.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-08-25 02:20:31
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-08-25 03:05: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 == 264 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) |