You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
(23) |
2
(40) |
3
(17) |
4
(10) |
|
5
(14) |
6
(41) |
7
(26) |
8
(23) |
9
(15) |
10
(25) |
11
(14) |
|
12
(23) |
13
(11) |
14
(18) |
15
(21) |
16
(18) |
17
(8) |
18
(14) |
|
19
(16) |
20
(15) |
21
(12) |
22
(11) |
23
(8) |
24
(11) |
25
(12) |
|
26
(9) |
27
(17) |
28
(31) |
29
(16) |
30
(10) |
31
(17) |
|
|
From: <sv...@va...> - 2006-03-15 23:57:53
|
Author: sewardj Date: 2006-03-15 23:57:50 +0000 (Wed, 15 Mar 2006) New Revision: 5772 Log: Tag for valgrind-3.1.1 (copy of VALGRIND_3_1_BRANCH r5771) Added: tags/VALGRIND_3_1_1/ Copied: tags/VALGRIND_3_1_1 (from rev 5771, branches/VALGRIND_3_1_BRANCH) |
|
From: <sv...@va...> - 2006-03-15 23:54:17
|
Author: sewardj Date: 2006-03-15 23:54:10 +0000 (Wed, 15 Mar 2006) New Revision: 1598 Log: Tag for valgrind-3.1.1 (copy of VALGRIND_3_1_BRANCH r1597) Added: tags/VEX_3_1_1/ Copied: tags/VEX_3_1_1 (from rev 1597, branches/VEX_3_1_BRANCH) |
|
From: <sv...@va...> - 2006-03-15 17:53:11
|
Author: sewardj
Date: 2006-03-15 17:53:06 +0000 (Wed, 15 Mar 2006)
New Revision: 5771
Log:
Hopefully final commit for 3.1.1.
Modified:
branches/VALGRIND_3_1_BRANCH/NEWS
branches/VALGRIND_3_1_BRANCH/configure.in
Modified: branches/VALGRIND_3_1_BRANCH/NEWS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VALGRIND_3_1_BRANCH/NEWS 2006-03-15 17:38:42 UTC (rev 5770)
+++ branches/VALGRIND_3_1_BRANCH/NEWS 2006-03-15 17:53:06 UTC (rev 5771)
@@ -11,14 +11,14 @@
n-i-bz ppc32: __NR_{set,get}priority
117332 x86: missing line info with icc 8.1
117366 amd64: 0xDD 0x7C fnstsw
-=3D=3D 118274
+118274 =3D=3D 117366
117367 amd64: 0xD9 0xF4 fxtract
117369 amd64: __NR_getpriority (140)
117419 ppc32: lfsu f5, -4(r11)
117419 ppc32: fsqrt
117936 more stabs problems (segfaults while reading debug info)
-=3D=3D119914
-=3D=3D120345
+119914 =3D=3D 117936
+120345 =3D=3D 117936
118239 amd64: 0xF 0xAE 0x3F (clflush)
118939 vm86old system call
n-i-bz memcheck/tests/mempool reads freed memory
@@ -49,7 +49,9 @@
119482 ppc32: mtfsb1
n-i-bz ppc32: mtocrf/mfocrf
=20
+(3.1.1: 15 March 2006, vex r1597, valgrind r5771).
=20
+
Release 3.1.0 (25 November 2005)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.1.0 is a feature release with a number of significant improvements:
Modified: branches/VALGRIND_3_1_BRANCH/configure.in
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VALGRIND_3_1_BRANCH/configure.in 2006-03-15 17:38:42 UTC (re=
v 5770)
+++ branches/VALGRIND_3_1_BRANCH/configure.in 2006-03-15 17:53:06 UTC (re=
v 5771)
@@ -1,5 +1,5 @@
# Process this file with autoconf to produce a configure script.
-AC_INIT(Valgrind, 3.1.0, val...@li...)
+AC_INIT(Valgrind, 3.1.1, val...@li...)
AC_CONFIG_SRCDIR(coregrind/m_main.c)
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE
|
|
From: <sv...@va...> - 2006-03-15 17:38:46
|
Author: sewardj
Date: 2006-03-15 17:38:42 +0000 (Wed, 15 Mar 2006)
New Revision: 5770
Log:
Merge r5769 (add a suppression for ld-2.4.so)
Modified:
branches/VALGRIND_3_1_BRANCH/glibc-2.4.supp
Modified: branches/VALGRIND_3_1_BRANCH/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
--- branches/VALGRIND_3_1_BRANCH/glibc-2.4.supp 2006-03-15 17:27:56 UTC (=
rev 5769)
+++ branches/VALGRIND_3_1_BRANCH/glibc-2.4.supp 2006-03-15 17:38:42 UTC (=
rev 5770)
@@ -44,6 +44,15 @@
}
=20
{
+ Fedora-Core-5-hack2a
+ Memcheck:Cond
+ obj:/lib*/ld-2.4*so
+ obj:/lib*/ld-2.4*so
+ obj:/lib*/ld-2.4*so
+ obj:/lib*/ld-2.4*so
+}
+
+{
Fedora-Core-5-hack3
Memcheck:Cond
obj:/lib*/ld-2.3.90.so
|
|
From: <sv...@va...> - 2006-03-15 17:28:07
|
Author: sewardj
Date: 2006-03-15 17:27:56 +0000 (Wed, 15 Mar 2006)
New Revision: 5769
Log:
Recycle Dirk's glibc-2.3.90 suppressions, since at some point it will
really become glibc-2.4.
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-03-15 14:18:16 UTC (rev 5768)
+++ trunk/glibc-2.4.supp 2006-03-15 17:27:56 UTC (rev 5769)
@@ -44,6 +44,15 @@
}
=20
{
+ Fedora-Core-5-hack2a
+ Memcheck:Cond
+ obj:/lib*/ld-2.4*so
+ obj:/lib*/ld-2.4*so
+ obj:/lib*/ld-2.4*so
+ obj:/lib*/ld-2.4*so
+}
+
+{
Fedora-Core-5-hack3
Memcheck:Cond
obj:/lib*/ld-2.3.90.so
|
|
From: <sv...@va...> - 2006-03-15 14:18:21
|
Author: sewardj
Date: 2006-03-15 14:18:16 +0000 (Wed, 15 Mar 2006)
New Revision: 5768
Log:
Allow a thread to spin longer when yielding before switching to a
different thread.
Modified:
branches/VALGRIND_3_1_BRANCH/coregrind/m_scheduler/scheduler.c
Modified: branches/VALGRIND_3_1_BRANCH/coregrind/m_scheduler/scheduler.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VALGRIND_3_1_BRANCH/coregrind/m_scheduler/scheduler.c 2006-0=
3-15 12:14:17 UTC (rev 5767)
+++ branches/VALGRIND_3_1_BRANCH/coregrind/m_scheduler/scheduler.c 2006-0=
3-15 14:18:16 UTC (rev 5768)
@@ -736,8 +736,8 @@
before swapping to another. That means that short term
spins waiting for hardware to poke memory won't cause a
thread swap. */
- if (VG_(dispatch_ctr) > 100)=20
- VG_(dispatch_ctr) =3D 100;
+ if (VG_(dispatch_ctr) > 2000)=20
+ VG_(dispatch_ctr) =3D 2000;
break;
=20
case VG_TRC_INNER_COUNTERZERO:
|
|
From: <sv...@va...> - 2006-03-15 13:12:58
|
Author: sewardj
Date: 2006-03-15 13:12:43 +0000 (Wed, 15 Mar 2006)
New Revision: 1597
Log:
Sheesh. The ppc32 back end is good at eating bazillions of spill
slots sometimes.
Modified:
branches/VEX_3_1_BRANCH/pub/libvex.h
Modified: branches/VEX_3_1_BRANCH/pub/libvex.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
--- branches/VEX_3_1_BRANCH/pub/libvex.h 2006-03-14 19:14:59 UTC (rev 159=
6)
+++ branches/VEX_3_1_BRANCH/pub/libvex.h 2006-03-15 13:12:43 UTC (rev 159=
7)
@@ -242,7 +242,7 @@
On entry, the baseblock pointer register must be 8-aligned.
*/
=20
-#define LibVEX_N_SPILL_BYTES 1536
+#define LibVEX_N_SPILL_BYTES 2048
=20
=20
/*-------------------------------------------------------*/
|
|
From: <sv...@va...> - 2006-03-15 12:14:20
|
Author: sewardj Date: 2006-03-15 12:14:17 +0000 (Wed, 15 Mar 2006) New Revision: 5767 Log: Finalise for 3.1.1. Modified: branches/VALGRIND_3_1_BRANCH/NEWS Modified: branches/VALGRIND_3_1_BRANCH/NEWS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- branches/VALGRIND_3_1_BRANCH/NEWS 2006-03-15 12:13:30 UTC (rev 5766) +++ branches/VALGRIND_3_1_BRANCH/NEWS 2006-03-15 12:14:17 UTC (rev 5767) @@ -1,5 +1,5 @@ =20 -Release 3.1.1 (11 March 2006) +Release 3.1.1 (15 March 2006) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.1.1 fixes a bunch of bugs reported in 3.1.0. There is no new functionality. The fixed bugs are: @@ -32,6 +32,7 @@ n-i-bz VG_(getgroups) fix (Shinichi Noda) n-i-bz ppc32: allocate from callee-saved FP/VMX regs n-i-bz misaligned path word-size bug in mc_main.c +119297 Incorrect error message for sse code 120410 x86: prefetchw (0xF 0xD 0x48 0x4) 120728 TIOCSERGETLSR, TIOCGICOUNT, HDIO_GET_DMA ioctls 120658 Build fixes for gcc 2.96 @@ -43,7 +44,7 @@ 121901 no support for syscall tkill n-i-bz Suppression update for Debian unstable 122067 amd64: fcmovnu (0xDB 0xD9) -n-i-bz ppc32: broken signal handling cpu feature detection +n-i-bz ppc32: broken signal handling in cpu feature detection n-i-bz ppc32: rounding mode problems (improved, partial fix only) 119482 ppc32: mtfsb1 n-i-bz ppc32: mtocrf/mfocrf |
|
From: <sv...@va...> - 2006-03-15 12:13:39
|
Author: sewardj
Date: 2006-03-15 12:13:30 +0000 (Wed, 15 Mar 2006)
New Revision: 5766
Log:
Merge r5765 (A couple of initialisations to keep gcc-4.1.0 happy.)
Modified:
branches/VALGRIND_3_1_BRANCH/coregrind/m_aspacemgr/aspacemgr.c
branches/VALGRIND_3_1_BRANCH/coregrind/m_main.c
Modified: branches/VALGRIND_3_1_BRANCH/coregrind/m_aspacemgr/aspacemgr.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VALGRIND_3_1_BRANCH/coregrind/m_aspacemgr/aspacemgr.c 2006-0=
3-15 11:50:32 UTC (rev 5765)
+++ branches/VALGRIND_3_1_BRANCH/coregrind/m_aspacemgr/aspacemgr.c 2006-0=
3-15 12:13:30 UTC (rev 5766)
@@ -3228,6 +3228,8 @@
UWord maj, min, dev;
ULong foffset;
=20
+ foffset =3D ino =3D 0; /* keep gcc-4.1.0 happy */
+
read_procselfmaps_into_buf();
=20
aspacem_assert('\0' !=3D procmap_buf[0] && 0 !=3D buf_n_tot);
Modified: branches/VALGRIND_3_1_BRANCH/coregrind/m_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
--- branches/VALGRIND_3_1_BRANCH/coregrind/m_main.c 2006-03-15 11:50:32 U=
TC (rev 5765)
+++ branches/VALGRIND_3_1_BRANCH/coregrind/m_main.c 2006-03-15 12:13:30 U=
TC (rev 5766)
@@ -1904,7 +1904,7 @@
Addr initial_client_SP =3D 0;
Addr clstack_top =3D 0;
SizeT clstack_max_size =3D 0;
- UInt* client_auxv;
+ UInt* client_auxv =3D NULL;
Int loglevel, i;
Bool logging_to_fd;
struct vki_rlimit zero =3D { 0, 0 };
|
|
From: <sv...@va...> - 2006-03-15 11:50:38
|
Author: sewardj
Date: 2006-03-15 11:50:32 +0000 (Wed, 15 Mar 2006)
New Revision: 5765
Log:
A couple of initialisations to keep gcc-4.1.0 happy.
Modified:
trunk/coregrind/m_aspacemgr/aspacemgr.c
trunk/coregrind/m_main.c
Modified: trunk/coregrind/m_aspacemgr/aspacemgr.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_aspacemgr/aspacemgr.c 2006-03-14 00:56:29 UTC (rev =
5764)
+++ trunk/coregrind/m_aspacemgr/aspacemgr.c 2006-03-15 11:50:32 UTC (rev =
5765)
@@ -3228,6 +3228,8 @@
UWord maj, min, dev;
ULong foffset;
=20
+ foffset =3D ino =3D 0; /* keep gcc-4.1.0 happy */
+
read_procselfmaps_into_buf();
=20
aspacem_assert('\0' !=3D procmap_buf[0] && 0 !=3D buf_n_tot);
Modified: trunk/coregrind/m_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/coregrind/m_main.c 2006-03-14 00:56:29 UTC (rev 5764)
+++ trunk/coregrind/m_main.c 2006-03-15 11:50:32 UTC (rev 5765)
@@ -1951,7 +1951,7 @@
Addr initial_client_TOC =3D 0;
Addr clstack_top =3D 0;
SizeT clstack_max_size =3D 0;
- UInt* client_auxv;
+ UInt* client_auxv =3D NULL;
Int loglevel, i;
Bool logging_to_fd;
struct vki_rlimit zero =3D { 0, 0 };
|
|
From: <js...@ac...> - 2006-03-15 11:03:12
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-03-15 02:00:01 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 194 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Josef W. <Jos...@gm...> - 2006-03-15 09:44:13
|
On Tuesday 14 March 2006 23:48, Nicholas Nethercote wrote: > On Tue, 14 Mar 2006, Josef Weidendorfer wrote: > > > With the (to be) 3.2.0/3.1.1 the demangler replaces __libc_start_main with > > "(below main)". I am not sure this is a good thing in general, > > especially for tools where symbol names in the output are expected > > to be as precise as possible (like eg. callgrind :-). > > There already is the --show-below-main flag, looks like the code in > VG_(demangle)() should be made conditional on it. I thought that --show-below-main=no does stop printing a backtrace at main, ie. this never would show this "(below main)" symbol, so no need to bother changing the symbol name at the first place? > And Callgrind could then > set --show-below-main=no at startup. Julian, do you agree? This option is about changing the behavior of stack backtraces in error messages, and AFAICS the "(below main)" hack is about the same thing (backtraces), but done at a way too low level (at demangling time), which means that tools never will be able to see symbols like "__libc_start_main" for there own special handling. Also, tools now have to expect that symbols can start with a parenthesis. Why not simply do this "(below main)" thing when printing out the backtraces (and before matching any suppresions), possibly in an additional function VG_(mangle_for_backtrace_output)() ? > The comparison against __libc_start_main and generic_start_main is also done > in m_stacktrace.c:VG_(apply_StackTrace)() -- looks like it should be > factored out from those two places into a separate function. Yes. Josef > > Nick > > |
|
From: Josef W. <Jos...@gm...> - 2006-03-15 09:28:21
|
As far as I understand this... On Tuesday 14 March 2006 23:39, Nicholas Nethercote wrote: > > No. I was trying to say that wrapping is thread safe - each thread's Thread safe means that the wrapping mechanism is safe to be used together with multithreaded code. > > wrapping activities are completely independent. If a wrapper function > > accesses global data then perhaps it does need locking, but that's > > just standard requirements for multithreaded programming. For wrapper functions to be thread safe, they have to be reentrant, as VGs scheduler is allowed everytime (*) while a wrapper is running to switch to another thread, which could happen to run the same wrapper at the same time. Ie. this means not to use global vars or do locking for them. > But Valgrind forces programs to run single-threaded, right? So no locking > should be necessary in wrapper functions provided by tools? Wrapper functions themself run on the simulated CPU, and therefore a thread switch can happen everytime. So the wrapper has to be reentrant. Of course, the handling of a client request triggered by the wrapper does not be reentrant. Josef (*) In the past, I thought that it is safe to expect that VGs scheduler will only switch threads at BB boundaries (nowadays Superblocks), but this is obviously wrong when looking at Segfault or FP exceptions, which can happen everytime. |
|
From: Ashley P. <as...@qu...> - 2006-03-15 08:59:10
|
On Wed, 2006-03-15 at 09:39 +1100, Nicholas Nethercote wrote: > On Tue, 14 Mar 2006, Julian Seward wrote: > > >> Thanks for writing documentation about function wrapping. If I > >> understand you correctly then wrapped functions run multithreaded ? > > > > No. > > > >> Does this imply that if a wrapper function accesses global data, that > >> locking is required ? > > > > No. I was trying to say that wrapping is thread safe - each thread's > > wrapping activities are completely independent. If a wrapper function > > accesses global data then perhaps it does need locking, but that's > > just standard requirements for multithreaded programming. > > But Valgrind forces programs to run single-threaded, right? So no locking > should be necessary in wrapper functions provided by tools? That doesn't sound right to me, valgrind only forces processes to run single-threaded in the same was as running them on a UP box does. It's not possible to predict when or prevent another thread from starting hence locking of global state will be needed. Ashley, |
|
From: <js...@ac...> - 2006-03-15 04:58:33
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-03-15 03:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 225 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Libin V. <li...@gm...> - 2006-03-15 04:51:32
|
Nicholas Nethercote wrote: > On Tue, 14 Mar 2006, Libin Varghese wrote: > >> I am not able to understand the hashing algorithm < static UInt >> hash_LockSet_w_wo(const LockSet *ls, const Mutex *with, const Mutex >> *without) >>> used for the Locksets. So could someone please explain it to me. > > Looks like it just goes through the lockset and, for each entry, if it > matches some criteria does some bit fiddling (left rotate and XORing). I am interested to find out what that criteria is? How does this hashing algo make a key unique. ~Libin |
|
From: <js...@ac...> - 2006-03-15 03:54:56
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-03-15 04:40:00 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 == 199 tests, 6 stderr failures, 2 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/ppc32/mftocrf (stdout) |
|
From: Tom H. <th...@cy...> - 2006-03-15 03:33:15
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-03-15 03:15:08 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 == 226 tests, 21 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-03-15 03:26:16
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-03-15 03:10:07 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 == 249 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == 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 == 249 tests, 6 stderr failures, 2 stdout failures ================= memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Mar 15 03:19:00 2006 --- new.short Wed Mar 15 03:26:05 2006 *************** *** 8,11 **** ! == 249 tests, 6 stderr failures, 2 stdout failures ================= ! memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 249 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/pointer-trace (stderr) |
|
From: Tom H. <th...@cy...> - 2006-03-15 03:25:22
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-03-15 03:05:13 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 == 249 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-03-15 03:24:29
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-03-15 03:00: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 == 249 tests, 7 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |