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-16 22:40:52
|
I am doing some validation of the latest valgrind code on some ppc64 systems.
One problem I've run into is that a number of memcheck/tests are failing because
the stderr output shows some line numbers that are off by 1-3 lines compared to
what's expected. I'm not seeing this on x86 -- just ppc64. For example,
memcheck/tests/addressable fails as follows:
----------------------------------
--- addressable.stderr.exp 2011-09-14 12:08:53.000000000 -0500
+++ addressable.stderr.out 2011-09-14 12:47:35.000000000 -0500
@@ -9,7 +9,7 @@
For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Unaddressable byte(s) found during client check request
- at 0x........: test2 (addressable.c:48)
+ at 0x........: test2 (addressable.c:51)
by 0x........: main (addressable.c:125)
Address 0x........ is not stack'd, malloc'd or (recently) free'd
----------------------------------
Notably, the same testcase runs fine in valgrind 3.6.1. And I see no changes to
the testcase or expected output between 3.6.1 and current SVN code. I see this
problem on both ppc64 systems I've tested on so far, one being a POWER7/SLES 11
SP1 and the other a POWER5/SLES 10 SP3. Does anyone have any idea what may have
changed in regards to debuginfo collection between 3.6.1 and present? I'll
continue to dig, but hoping someone can short-circuit the search by pointing me
in the right direction.
Thanks.
-Maynard
|
|
From: Rich C. <rc...@wi...> - 2011-09-16 21:22:53
|
Hi Maynard, This is all very weird. I'll see if I can reproduce it on a fresh install if SLES 10 SP2. Rich On Fri, 16 Sep 2011 15:13:07 -0500 Maynard Johnson <may...@us...> wrote: > On 09/16/2011 10:10 AM, Rich Coe wrote: > > The nightly build runs on opensuse-11.4 and doesn't see the error. > > opensuse is similar to but not the same as SLES. > > > > Can you run the following and track down the header reference? > > cd memcheck/tests/x86-linux > > 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" \ > > -E -o scalar.e scalar.c > > > > Then look at scalar.e and see what header is defining struct timespec and > > struct timeval in ahead of time.h ??? > > Rich, > Firstly, I want to add that apparently this is *not* a new problem. I pulled > down 3.6.1 today and am seeing the same problem there. I hacked the > memcheck/tests/Makefile.am so the 'make check' won't even try to build > x86-linux, so I got the build to complete and ran 'make regtest'. My main > reason for running on this platform was just for comparison purposes to the > ppc64 platform I'm working on. So this problem is not critical for me. > Nevertheless, I ran the above command you suggested, but it did not complete > successfully -- no scalar.e was produced. Here's the output: > > --------------------------------------- > mpj@elm3b21:~/valg_svn_09.15.2011/memcheck/tests/x86-linux> 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" -E -o scalar.e scalar.c > In file included from /usr/include/linux/sched.h:12, > 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/jiffies.h:250:47: error: division by zero in #if > /usr/include/linux/jiffies.h:261:47: error: division by zero in #if > /usr/include/linux/jiffies.h:274:47: error: division by zero in #if > /usr/include/linux/jiffies.h:287:47: error: division by zero in #if > /usr/include/linux/jiffies.h:379:41: error: division by zero in #if > /usr/include/linux/jiffies.h:379:42: error: division by zero in #if > /usr/include/linux/jiffies.h:390:18: error: division by zero in #if > /usr/include/linux/jiffies.h:410:41: error: division by zero in #if > /usr/include/linux/jiffies.h:410:42: error: division by zero in #if > /usr/include/linux/jiffies.h:426:28: error: division by zero in #if > In file included from /usr/include/linux/signal.h:4, > from /usr/include/linux/sched.h:28, > 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/list.h:814:2: warning: #warning "don't include kernel headers > in userspace" > --------------------------------------- > > > The source code for the first "division by zero" error at line 250 of jiffies.h is: > #elif HZ > MSEC_PER_SEC && !(HZ % MSEC_PER_SEC) > > It seems all of these errors are either for MSEC_PER_SEC or USEC_PER_SEC not > defined. The only place I see them defined is in /usr/include/linux/time.h > within an #ifdef __kernel__ block. > > Regards, > -Maynard > > > > > > > > The start of each header will be in the output on line starting with '#'. > > > > Rich > > > > On Thu, 15 Sep 2011 17:53:40 -0500 > > Maynard Johnson<may...@us...> wrote: > >> 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 > >> > >> > >> ------------------------------------------------------------------------------ > >> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > >> http://p.sf.net/sfu/rim-devcon-copy2 > >> _______________________________________________ > >> Valgrind-developers mailing list > >> Val...@li... > >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > -- Rich Coe rc...@wi... |
|
From: Maynard J. <may...@us...> - 2011-09-16 20:13:22
|
On 09/16/2011 10:10 AM, Rich Coe wrote:
> The nightly build runs on opensuse-11.4 and doesn't see the error.
> opensuse is similar to but not the same as SLES.
>
> Can you run the following and track down the header reference?
> cd memcheck/tests/x86-linux
> 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" \
> -E -o scalar.e scalar.c
>
> Then look at scalar.e and see what header is defining struct timespec and
> struct timeval in ahead of time.h ???
Rich,
Firstly, I want to add that apparently this is *not* a new problem. I pulled
down 3.6.1 today and am seeing the same problem there. I hacked the
memcheck/tests/Makefile.am so the 'make check' won't even try to build
x86-linux, so I got the build to complete and ran 'make regtest'. My main
reason for running on this platform was just for comparison purposes to the
ppc64 platform I'm working on. So this problem is not critical for me.
Nevertheless, I ran the above command you suggested, but it did not complete
successfully -- no scalar.e was produced. Here's the output:
---------------------------------------
mpj@elm3b21:~/valg_svn_09.15.2011/memcheck/tests/x86-linux> 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" -E -o scalar.e scalar.c
In file included from /usr/include/linux/sched.h:12,
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/jiffies.h:250:47: error: division by zero in #if
/usr/include/linux/jiffies.h:261:47: error: division by zero in #if
/usr/include/linux/jiffies.h:274:47: error: division by zero in #if
/usr/include/linux/jiffies.h:287:47: error: division by zero in #if
/usr/include/linux/jiffies.h:379:41: error: division by zero in #if
/usr/include/linux/jiffies.h:379:42: error: division by zero in #if
/usr/include/linux/jiffies.h:390:18: error: division by zero in #if
/usr/include/linux/jiffies.h:410:41: error: division by zero in #if
/usr/include/linux/jiffies.h:410:42: error: division by zero in #if
/usr/include/linux/jiffies.h:426:28: error: division by zero in #if
In file included from /usr/include/linux/signal.h:4,
from /usr/include/linux/sched.h:28,
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/list.h:814:2: warning: #warning "don't include kernel headers
in userspace"
---------------------------------------
The source code for the first "division by zero" error at line 250 of jiffies.h is:
#elif HZ > MSEC_PER_SEC && !(HZ % MSEC_PER_SEC)
It seems all of these errors are either for MSEC_PER_SEC or USEC_PER_SEC not
defined. The only place I see them defined is in /usr/include/linux/time.h
within an #ifdef __kernel__ block.
Regards,
-Maynard
>
> The start of each header will be in the output on line starting with '#'.
>
> Rich
>
> On Thu, 15 Sep 2011 17:53:40 -0500
> Maynard Johnson<may...@us...> wrote:
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
>> http://p.sf.net/sfu/rim-devcon-copy2
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
>
|
|
From: Rich C. <rc...@wi...> - 2011-09-16 15:10:28
|
The nightly build runs on opensuse-11.4 and doesn't see the error. opensuse is similar to but not the same as SLES. Can you run the following and track down the header reference? cd memcheck/tests/x86-linux 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" \ -E -o scalar.e scalar.c Then look at scalar.e and see what header is defining struct timespec and struct timeval in ahead of time.h ??? The start of each header will be in the output on line starting with '#'. Rich On Thu, 15 Sep 2011 17:53:40 -0500 Maynard Johnson <may...@us...> wrote: > 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 > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers -- Rich Coe rc...@wi... |
|
From: Bart V. A. <bva...@ac...> - 2011-09-16 15:01:51
|
On Thu, Sep 15, 2011 at 6:35 PM, Florian Krohm <br...@ac...> wrote:
> 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.
Second try ... does the attached patch help (also included below) ?
Bart.
Index: configure.in
===================================================================
--- configure.in (revision 12034)
+++ configure.in (working copy)
@@ -1629,6 +1629,22 @@ AC_CHECK_HEADERS([ \
sys/types.h \
])
+# Verify whether the <linux/futex.h> header is usable.
+AC_MSG_CHECKING([if <linux/futex.h> is usable])
+
+AC_TRY_COMPILE([
+#include <linux/futex.h>
+], [
+ return FUTEX_WAIT;
+],
+[
+AC_DEFINE([HAVE_USABLE_LINUX_FUTEX_H], 1,
+ [Define to 1 if you have a usable <linux/futex.h> header file.])
+AC_MSG_RESULT([yes])
+], [
+AC_MSG_RESULT([no])
+])
+
#----------------------------------------------------------------------------
# Checks for typedefs, structures, and compiler characteristics.
#----------------------------------------------------------------------------
Index: drd/drd_pthread_intercepts.c
===================================================================
--- drd/drd_pthread_intercepts.c (revision 12034)
+++ drd/drd_pthread_intercepts.c (working copy)
@@ -56,14 +56,14 @@
#include <stdio.h> /* fprintf() */
#include <stdlib.h> /* malloc(), free() */
#include <unistd.h> /* confstr() */
-#ifdef __linux__
+#include "config.h" /* HAVE_PTHREAD_MUTEX_ADAPTIVE_NP etc. */
+#ifdef HAVE_USABLE_LINUX_FUTEX_H
#include <asm/unistd.h> /* __NR_futex */
#include <linux/futex.h> /* FUTEX_WAIT */
#ifndef FUTEX_PRIVATE_FLAG
#define FUTEX_PRIVATE_FLAG 0
#endif
#endif
-#include "config.h" /* HAVE_PTHREAD_MUTEX_ADAPTIVE_NP etc. */
#include "drd_basics.h" /* DRD_() */
#include "drd_clientreq.h"
#include "pub_tool_redir.h" /* VG_WRAP_FUNCTION_ZZ() */
@@ -194,7 +194,7 @@ static void DRD_(sema_down)(DrdSema* sem
int res = ENOSYS;
while (sema->counter == 0) {
-#if defined(__linux__) && defined(__NR_futex)
+#ifdef HAVE_USABLE_LINUX_FUTEX_H
if (syscall(__NR_futex, (UWord)&sema->counter,
FUTEX_WAIT | FUTEX_PRIVATE_FLAG, 0) == 0)
res = 0;
@@ -216,7 +216,7 @@ static void DRD_(sema_down)(DrdSema* sem
static void DRD_(sema_up)(DrdSema* sema)
{
sema->counter++;
-#if defined(__linux__) && defined(__NR_futex)
+#ifdef HAVE_USABLE_LINUX_FUTEX_H
syscall(__NR_futex, (UWord)&sema->counter,
FUTEX_WAKE | FUTEX_PRIVATE_FLAG, 1);
#endif
|