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
(5) |
2
(15) |
3
(20) |
|
4
(4) |
5
(11) |
6
(8) |
7
(36) |
8
(23) |
9
(6) |
10
(4) |
|
11
(4) |
12
(19) |
13
(17) |
14
(33) |
15
(16) |
16
(17) |
17
(4) |
|
18
(4) |
19
(30) |
20
(22) |
21
(23) |
22
(29) |
23
(20) |
24
(12) |
|
25
(7) |
26
(33) |
27
(10) |
28
(12) |
29
(19) |
30
(15) |
31
(8) |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-30 22:39:23
|
On Wed, Jan 28, 2009 at 10:14 PM, Julian Seward <js...@ac...> wrote: > > If there are any other high priority bug fixes that should go in > 3.4.1, please let me know, preferably with trunk rev numbers. But > please no build system changes. On Monday I might have a fix for some borked line number reading in the stabs reader, believe it or not -- I was looking into it for the Darwin port because DWARF is such a pain on Darwin. But it probably doesn't matter for 3.4.1, I don't think stabs gets much use any more. N |
|
From: Bart V. A. <bar...@gm...> - 2009-01-30 19:45:24
|
On Thu, Jan 29, 2009 at 11:54 AM, Julian Seward <js...@ac...> wrote: > >> I would like to see r9087 to go in release 3.4.1. But maybe it's best >> to wait for the next nightly build results before merging this change. > > I already added it to my list of stuff-that-needs-to-be-merged. But > if you want to wait for test results, then fine; just lmk in the next > few days if you want it merged. Can you please merge the trunk revisions 9087, 9090, 9091 and 9092 to the 3.4.1 branch ? The descriptions are as follows: ------------------------------------------------------------------------ r9092 | bart | 2009-01-30 19:31:54 +0100 (Fri, 30 Jan 2009) | 1 line Removed mandatory redirections for DRD since these made DRD impossible to use on openSUSE 10.3 ppc. ------------------------------------------------------------------------ r9091 | bart | 2009-01-30 18:52:39 +0100 (Fri, 30 Jan 2009) | 1 line Generalized suppression patterns. ------------------------------------------------------------------------ r9090 | bart | 2009-01-30 18:52:21 +0100 (Fri, 30 Jan 2009) | 1 line Do not only recognize .plt and .plt.got sections inside the mapped address range, but also outside the mapped address range (necessary for ppc). ------------------------------------------------------------------------ r9087 | bart | 2009-01-29 10:57:22 +0100 (Thu, 29 Jan 2009) | 1 line Suppress any error whose top frame is in libc.so. While not very elegant, this is an effective way to suppress data race reports triggered by glibc's stdio functions (which uses inlined locking functions). ------------------------------------------------------------------------ Thanks, Bart. |
|
From: <sv...@va...> - 2009-01-30 18:32:00
|
Author: bart
Date: 2009-01-30 18:31:54 +0000 (Fri, 30 Jan 2009)
New Revision: 9092
Log:
Removed mandatory redirections for DRD since these made DRD impossible to use on openSUSE 10.3 ppc.
Modified:
trunk/coregrind/m_redir.c
Modified: trunk/coregrind/m_redir.c
===================================================================
--- trunk/coregrind/m_redir.c 2009-01-30 17:52:39 UTC (rev 9091)
+++ trunk/coregrind/m_redir.c 2009-01-30 18:31:54 UTC (rev 9092)
@@ -906,15 +906,6 @@
NULL /* not mandatory - so why bother at all? */
/* glibc-2.6.1 (openSUSE 10.3, ppc32) seems fine without it */
);
- } else if (0 == VG_(strcmp)("drd", VG_(details).name)) {
- /* Only continue if symbol information in ld.so.1 is present, */
- /* because otherwise drd's suppression patterns on ld.so do */
- /* not have any effect. */
- add_hardwired_spec(
- "ld.so.1", "strlen",
- (Addr)(&VG_(ppc32_linux_REDIR_FOR_strlen)),
- croakage
- );
}
}
@@ -940,16 +931,6 @@
NULL /* not mandatory - so why bother at all? */
/* glibc-2.5 (FC6, ppc64) seems fine without it */
);
-
- } else if (0 == VG_(strcmp)("drd", VG_(details).name)) {
- /* Only continue if symbol information in ld64.so.1 is present, */
- /* because otherwise drd's suppression patterns on ld.so do */
- /* not have any effect. */
- add_hardwired_spec(
- "ld64.so.1", "strlen",
- (Addr)VG_(fnptr_to_fnentry)( &VG_(ppc64_linux_REDIR_FOR_strlen) ),
- croakage
- );
}
}
|
|
From: Konstantin S. <kon...@gm...> - 2009-01-30 17:59:49
|
On Fri, Jan 30, 2009 at 7:51 PM, Julian Seward <js...@ac...> wrote: > >> /usr/grte/v1//include/linux/errno.h:#define ETIMEDOUT 110 >> /* Connection timed out */ > > Then it's a timing-related problem? What happens if you run with > --tool=none, can you still reproduce it? Same thing... kcc 29787 0.1 0.0 0 0 pts/11 Zl+ 19:57 0:06 [none] <defunct> |
|
From: <sv...@va...> - 2009-01-30 17:52:51
|
Author: bart
Date: 2009-01-30 17:52:39 +0000 (Fri, 30 Jan 2009)
New Revision: 9091
Log:
Generalized suppression patterns.
Modified:
trunk/glibc-2.X-drd.supp
Modified: trunk/glibc-2.X-drd.supp
===================================================================
--- trunk/glibc-2.X-drd.supp 2009-01-30 17:52:21 UTC (rev 9090)
+++ trunk/glibc-2.X-drd.supp 2009-01-30 17:52:39 UTC (rev 9091)
@@ -21,7 +21,6 @@
drd:ConflictingAccess
obj:/lib*/ld-*.so
obj:/lib*/ld-*.so
- obj:/lib*/ld-*.so
}
{
dl-dlsym-1
|
|
From: <sv...@va...> - 2009-01-30 17:52:26
|
Author: bart
Date: 2009-01-30 17:52:21 +0000 (Fri, 30 Jan 2009)
New Revision: 9090
Log:
Do not only recognize .plt and .plt.got sections inside the mapped address range, but also outside the mapped address range (necessary for ppc).
Modified:
trunk/drd/drd_main.c
Modified: trunk/drd/drd_main.c
===================================================================
--- trunk/drd/drd_main.c 2009-01-30 17:02:15 UTC (rev 9089)
+++ trunk/drd/drd_main.c 2009-01-30 17:52:21 UTC (rev 9090)
@@ -524,7 +524,8 @@
avma = VG_(seginfo_get_plt_avma)(di);
size = VG_(seginfo_get_plt_size)(di);
- if (size > 0 && a <= avma && avma + size <= a + len)
+ tl_assert((avma && size) || (avma == 0 && size == 0));
+ if (size > 0)
{
#if 0
VG_(printf)("Suppressing .plt @ 0x%lx size %ld\n", avma, size);
@@ -535,7 +536,8 @@
avma = VG_(seginfo_get_gotplt_avma)(di);
size = VG_(seginfo_get_gotplt_size)(di);
- if (size > 0 && a <= avma && avma + size <= a + len)
+ tl_assert((avma && size) || (avma == 0 && size == 0));
+ if (size > 0)
{
#if 0
VG_(printf)("Suppressing .got.plt @ 0x%lx size %ld\n", avma, size);
|
|
From: <sv...@va...> - 2009-01-30 17:02:27
|
Author: sewardj
Date: 2009-01-30 17:02:15 +0000 (Fri, 30 Jan 2009)
New Revision: 9089
Log:
merge r9084: Generalise zlib suppressions a bit.
Modified:
branches/VALGRIND_3_4_BRANCH/xfree-4.supp
Modified: branches/VALGRIND_3_4_BRANCH/xfree-4.supp
===================================================================
--- branches/VALGRIND_3_4_BRANCH/xfree-4.supp 2009-01-29 10:14:53 UTC (rev 9088)
+++ branches/VALGRIND_3_4_BRANCH/xfree-4.supp 2009-01-30 17:02:15 UTC (rev 9089)
@@ -315,6 +315,7 @@
zlib-1.2.x trickyness (1a): See http://www.zlib.net/zlib_faq.html#faq36
Memcheck:Cond
obj:/*lib*/libz.so.1.2.*
+ ...
obj:/*lib*/libz.so.1.2.*
fun:deflate
}
@@ -329,6 +330,7 @@
zlib-1.2.x trickyness (2a): See http://www.zlib.net/zlib_faq.html#faq36
Memcheck:Value8
obj:/*lib*/libz.so.1.2.*
+ ...
obj:/*lib*/libz.so.1.2.*
fun:deflate
}
@@ -343,6 +345,7 @@
zlib-1.2.x trickyness (3a): See http://www.zlib.net/zlib_faq.html#faq36
Memcheck:Value4
obj:/*lib*/libz.so.1.2.*
+ ...
obj:/*lib*/libz.so.1.2.*
fun:deflate
}
|
|
From: Julian S. <js...@ac...> - 2009-01-30 16:52:21
|
> /usr/grte/v1//include/linux/errno.h:#define ETIMEDOUT 110 > /* Connection timed out */ Then it's a timing-related problem? What happens if you run with --tool=none, can you still reproduce it? J |
|
From: Johannes S. <Joh...@gm...> - 2009-01-30 16:49:13
|
Hi, On Thu, 29 Jan 2009, Johannes Schindelin wrote: > So far I did not succeed in chopping it down. (It is still the .c file I > sent you, linked to zlib.) > > The thing that really gets me is that I littered a while() loop with > instructions like this: > > VALGRIND_CHECK_MEM_IS_DEFINED(s->strm->state->pending_out + 49, 1); > fprintf(stderr, "Z%02x %p\n", s->strm->state->pending_out[49], > s->strm->state->pending_out + 49); > > I also added such an instruction just before the end of the while loop, > and just after it. > > Unless my brain really turned into tatties, the check after the while loop > should not be able to trigger an error unless the one in the while() loop > does (yes, I checked that the loop body is actually executed, I > substituted the "Z" in the fprintf() with an "X" there, and it prints it). > > Yet the latter check triggers an error, and the former does not. > > FWIW the while() loop is in in trees.c, function compress_block() in > http://archive.ubuntu.com/ubuntu/pool/main/z/zlib/zlib_1.2.3.3.dfsg.orig.tar.gz > > Oh, and it had to be configured in this way: > > CFLAGS="-g -O3 -DUNALIGNED_OK" ./configure > > If you leave out either the -O3 or the define, the bug does not trigger. > > And like I said, this is x86_64; I could imagine that this bug is platform > dependent. FWIW the issue is also there with i386 (tested on a Pentium, though). I'll not have time to work on this until next week. Just a heads-up, Dscho |
|
From: Konstantin S. <kon...@gm...> - 2009-01-30 16:47:45
|
On Fri, Jan 30, 2009 at 7:39 PM, Julian Seward <js...@ac...> wrote: > >> > SYSCALL[7806,5](202) sys_futex ( 0x8427f20, 0, 0, 0x0, 0x8427f20 ) --> >> > [async] ... >> > SYSCALL[7806,4](202) ... [async] --> Failure(0x6e) >> > >> > If valgrind passes, it does not print lines containing "Failure(0x6e)" >> > >> > Any idea how to attack this problem further? > > This is with a completely vanilla, unmodified Valgrind, yes? yes, I verified it with today's trunk. > > Figure out what 0x6E means, so we can see why sys_futex is failing. > It's an Exxxx value (eg, ENOSYS, etc) logically from /usr/include/sys/errno.h. > Some of the values are defined in ./include/vki/vki*.h, but I can't find 0x6E > (110) there. /usr/grte/v1//include/linux/errno.h:#define ETIMEDOUT 110 /* Connection timed out */ > > J > |
|
From: Julian S. <js...@ac...> - 2009-01-30 16:40:27
|
> > SYSCALL[7806,5](202) sys_futex ( 0x8427f20, 0, 0, 0x0, 0x8427f20 ) --> > > [async] ... > > SYSCALL[7806,4](202) ... [async] --> Failure(0x6e) > > > > If valgrind passes, it does not print lines containing "Failure(0x6e)" > > > > Any idea how to attack this problem further? This is with a completely vanilla, unmodified Valgrind, yes? Figure out what 0x6E means, so we can see why sys_futex is failing. It's an Exxxx value (eg, ENOSYS, etc) logically from /usr/include/sys/errno.h. Some of the values are defined in ./include/vki/vki*.h, but I can't find 0x6E (110) there. J |
|
From: Konstantin S. <kon...@gm...> - 2009-01-30 16:02:00
|
Any idea? --kcc On Tue, Jan 20, 2009 at 4:29 PM, Konstantin Serebryany <kon...@gm...> wrote: > Hello, > > I am experiencing a problem with valgrind: the memcheck process > becomes zombie at the very end of the program execution. > This happens with the fresh valgrind trunk. > > I run > valgrind -v --trace-syscalls=yes my_program > and it hangs one out of 5-10 runs. > > 'top' shows: > 7806 me 18 0 0 0 0 Z 0 0.0 0:16.27 memcheck <defunct> > > The last lines printed by valgrind before it hangs are: > SYSCALL[7806,4]( 9) sys_mmap ( 0x0, 69632, 7, 98, -1, 0 ) --> > [pre-success] Success(0xbb6b000) > SYSCALL[7806,4]( 10) sys_mprotect ( 0xbb6b000, 4096, 0 )[sync] --> Success(0x0) > SYSCALL[7806,4]( 56) sys_clone ( 3d0f00, 0xbb7a1d0, 0xbb7b9f0, > 0xbb7b9f0, 0xbb7b960 ) --> [pre-success] Success(0x1f93) > SYSCALL[7806,4]( 96) sys_gettimeofday ( 0xb75bd70, 0x0 )[sync] --> Success(0x0) > SYSCALL[7806,4]( 96) sys_gettimeofday ( 0xb75bac0, 0x0 )[sync] --> Success(0x0) > SYSCALL[7806,4]( 96) sys_gettimeofday ( 0xb75bd70, 0x0 )[sync] --> Success(0x0) > SYSCALL[7806,4]( 96) sys_gettimeofday ( 0xb75bac0, 0x0 )[sync] --> Success(0x0) > SYSCALL[7806,4](202) sys_futex ( 0x8427820, 0, 0, 0xb75bb20, 0x8427820 > ) --> [async] ... > SYSCALL[7806,4](202) ... [async] --> Failure(0x6e) > SYSCALL[7806,4]( 96) sys_gettimeofday ( 0xb75bac0, 0x0 )[sync] --> Success(0x0) > SYSCALL[7806,4]( 96) sys_gettimeofday ( 0xb75bd70, 0x0 )[sync] --> Success(0x0) > SYSCALL[7806,4]( 96) sys_gettimeofday ( 0xb75bac0, 0x0 )[sync] --> Success(0x0) > SYSCALL[7806,4](202) sys_futex ( 0x8427820, 0, 0, 0xb75bb20, 0x8427820 > ) --> [async] ... > SYSCALL[7806,1]( 11) sys_munmap ( 0x8437000, 8192 )[sync] --> Success(0x0) > SYSCALL[7806,1](231) exit_group( 0 ) --> [pre-success] Success(0x0) > SYSCALL[7806,5](186) sys_gettid ()[sync] --> Success(0x1f93) > SYSCALL[7806,5](202) sys_futex ( 0x8427f20, 0, 0, 0x0, 0x8427f20 ) --> > [async] ... > SYSCALL[7806,4](202) ... [async] --> Failure(0x6e) > > If valgrind passes, it does not print lines containing "Failure(0x6e)" > > Any idea how to attack this problem further? > > Thanks, > > --kcc > |
|
From: Tom H. <th...@cy...> - 2009-01-30 03:47:53
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-01-30 03:20:06 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 486 tests, 1 stderr failure, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-30 03:44:31
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-01-30 03:05:11 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 == 477 tests, 6 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86-linux/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-30 03:31:44
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-01-30 03:10: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 == 483 tests, 5 stderr failures, 2 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/x86-linux/scalar (stderr) none/tests/mremap2 (stdout) |