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
|
2
(2) |
3
(7) |
|
4
|
5
(11) |
6
(13) |
7
(7) |
8
(5) |
9
(12) |
10
(19) |
|
11
(12) |
12
(7) |
13
(14) |
14
(8) |
15
(5) |
16
(5) |
17
(7) |
|
18
(12) |
19
(14) |
20
(12) |
21
(8) |
22
(4) |
23
(4) |
24
|
|
25
(11) |
26
(17) |
27
(15) |
28
(10) |
29
(19) |
30
(18) |
|
|
From: Maynard J. <may...@us...> - 2011-09-15 22:53:46
|
Hi,
I don't often build and run valgrind on x86 platforms, but today I checked out
the latest valgrind code on an Intel Xeon processor running SLES 10 SP2. The
valgrind code itself builds fine, but 'make check' fails in
memcheck/tests/x86-linux with the following error:
make[1]: Entering directory `/home/mpj/vg-09.12.2011/memcheck/tests/x86-linux'
make[1]: `bug133694' is up to date.
make[1]: `int3-x86' is up to date.
if gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../.. -I../../../include
-I../../../coregrind -I../../../include -I../../../VEX/pub -DVGA_amd64=1
-DVGO_linux=1 -DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1 -Winline -Wall
-Wshadow -g -m32 -mmmx -msse -Wno-long-long -Wno-pointer-sign
-fno-stack-protector -MT scalar.o -MD -MP -MF ".deps/scalar.Tpo" -c -o scalar.o
scalar.c; \
then mv -f ".deps/scalar.Tpo" ".deps/scalar.Po"; else rm -f ".deps/scalar.Tpo";
exit 1; fi
In file included from /usr/include/linux/timex.h:58,
from /usr/include/linux/sched.h:11,
from /usr/include/linux/mm.h:4,
from /usr/include/linux/mman.h:5,
from scalar.h:12,
from scalar.c:4:
/usr/include/linux/time.h:12: error: redefinition of ?struct timespec?
/usr/include/linux/time.h:18: error: redefinition of ?struct timeval?
In file included from /usr/include/asm/timex.h:6,
from /usr/include/linux/timex.h:61,
blah, blah, blah -- ad nauseum
Is this a known problem? I don't have any build problems on other platforms
(ppc64, amd64). I don't have another x86 system available with a newer distro
to see if I would have the same problem. Anyone else out there seeing this?
-Maynard
|
|
From: Florian K. <br...@ac...> - 2011-09-15 16:35:40
|
On 09/15/2011 12:11 PM, Bart Van Assche wrote:
>
>
> As you probably know that's a bug in the futex.h header. Does the
> patch below help ?
>
No. It does not. I'll be sending you the output of
cd /usr/include
find . -exec grep -H u32 {} \;
off list. There is no usable definition of u32 to be found.
Florian
> Bart.
>
> Index: drd/drd_pthread_intercepts.c
> ===================================================================
> --- drd/drd_pthread_intercepts.c (revision 12034)
> +++ drd/drd_pthread_intercepts.c (working copy)
> @@ -58,6 +58,7 @@
> #include <unistd.h> /* confstr() */
> #ifdef __linux__
> #include <asm/unistd.h> /* __NR_futex */
> +#include <linux/types.h>
> #include <linux/futex.h> /* FUTEX_WAIT */
> #ifndef FUTEX_PRIVATE_FLAG
> #define FUTEX_PRIVATE_FLAG 0
>
|
|
From: Bart V. A. <bva...@ac...> - 2011-09-15 16:12:12
|
On Thu, Sep 15, 2011 at 5:10 AM, Florian Krohm <br...@ac...> wrote: > > a colleague of mine at the IBM labs (who runs the BEAM checker every > once in a while) noticed that he can no longer compile valgrind. > The error occurs when compiling drd_pthread_intercepts.c: > > In file included from drd_pthread_intercepts.c:61: > /usr/include/linux/futex.h:96: error: expected ‘)’ before ‘*’ token > /usr/include/linux/futex.h:100: error: expected ‘)’ before ‘*’ token > > I'm including his futex.h. It's quite clear that the error is related to > the type u32 not being defined. As you probably know that's a bug in the futex.h header. Does the patch below help ? Bart. Index: drd/drd_pthread_intercepts.c =================================================================== --- drd/drd_pthread_intercepts.c (revision 12034) +++ drd/drd_pthread_intercepts.c (working copy) @@ -58,6 +58,7 @@ #include <unistd.h> /* confstr() */ #ifdef __linux__ #include <asm/unistd.h> /* __NR_futex */ +#include <linux/types.h> #include <linux/futex.h> /* FUTEX_WAIT */ #ifndef FUTEX_PRIVATE_FLAG #define FUTEX_PRIVATE_FLAG 0 |
|
From: Florian K. <br...@ac...> - 2011-09-15 04:17:13
|
This testcase causes a SIGILL on s390x. The reason for that is that
the 2nd argument of this pthread_cond_wait
/* mx is bogus */
r= pthread_cond_wait(&cv, (pthread_mutex_t*)(1 + (char*)&mx[0]) );
appears as the memory operand in a compare and swap instruction. And
that insn requires its memory operand to be word aligned. This one isn't.
So on s390x that testcase doesn't run through.
I'd like to change it like so:
Index: tc23_bogus_condwait.c
===================================================================
--- tc23_bogus_condwait.c (revision 12034)
+++ tc23_bogus_condwait.c (working copy)
@@ -66,7 +66,7 @@
trouble */
/* mx is bogus */
- r= pthread_cond_wait(&cv, (pthread_mutex_t*)(1 + (char*)&mx[0]) );
+ r= pthread_cond_wait(&cv, (pthread_mutex_t*)(4 + (char*)&mx[0]) );
/* mx is not locked */
r= pthread_cond_wait(&cv, &mx[0]);
Would that be OK or is it important for the testcase that the address is
odd?
Florian
|
|
From: Florian K. <br...@ac...> - 2011-09-15 03:11:03
|
Hello Bart, a colleague of mine at the IBM labs (who runs the BEAM checker every once in a while) noticed that he can no longer compile valgrind. The error occurs when compiling drd_pthread_intercepts.c: In file included from drd_pthread_intercepts.c:61: /usr/include/linux/futex.h:96: error: expected ‘)’ before ‘*’ token /usr/include/linux/futex.h:100: error: expected ‘)’ before ‘*’ token I'm including his futex.h. It's quite clear that the error is related to the type u32 not being defined. He has the following setup: $ uname -a Linux whatever.watson.ibm.com 2.6.18-92.1.13.el5PAE #1 SMP Thu Sep 4 4:05:54 EDT 2008 i686 i686 i386 GNU/Linux $ gcc --version gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42) $ /lib/libc*so GNU C Library stable release version 2.5, by Roland McGrath et al. Possible solutions are #ifndef u32 #define unsigned u32 #endif or throwing ouy futex.h and #ifndef FUTEX_WAIT #define FUTEX_WAIT 0 #endif which may be suitable if FUTEX_WAIT is not something internal (and so not likely to change). Yeah, I know, neither is particular pretty. But futex.h is broken to begin with. Florian |