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
(7) |
2
(5) |
3
(2) |
4
(8) |
5
(10) |
|
6
(3) |
7
(9) |
8
(7) |
9
(8) |
10
(7) |
11
(4) |
12
(11) |
|
13
(5) |
14
(17) |
15
(6) |
16
(15) |
17
|
18
(3) |
19
(1) |
|
20
(6) |
21
(18) |
22
(5) |
23
(9) |
24
(6) |
25
(3) |
26
(1) |
|
27
(1) |
28
|
29
(8) |
30
(5) |
|
|
|
|
From: Florian K. <fl...@ei...> - 2015-09-14 21:12:55
|
On 14.09.2015 22:46, Mark Wielaard wrote: > On Mon, Sep 14, 2015 at 10:12:59PM +0200, Florian Krohm wrote: >> However, I believe we should not ship code that, when compiled, spits >> out loads of warnings. That makes a pretty bad impression. >> So I'm proposing to not give -Wcast-align when compiling on arm. >> >> Any objections? > > No objection. The result clearly works. It looks like gcc is just > really conservative in this case. Warning just in case. > Done in r15651. Thanks for your help! Florian |
|
From: <sv...@va...> - 2015-09-14 21:11:41
|
Author: florian
Date: Mon Sep 14 22:11:32 2015
New Revision: 15651
Log:
Do not compile with -Wcast-align on arm. There are too many
warnings due to GCC being very conservative.
Modified:
trunk/Makefile.all.am
trunk/configure.ac
Modified: trunk/Makefile.all.am
==============================================================================
--- trunk/Makefile.all.am (original)
+++ trunk/Makefile.all.am Mon Sep 14 22:11:32 2015
@@ -100,12 +100,12 @@
-O2 -g \
-std=gnu99 \
-Wall \
- -Wcast-align \
-Wmissing-prototypes \
-Wshadow \
-Wpointer-arith \
-Wstrict-prototypes \
-Wmissing-declarations \
+ @FLAG_W_CAST_ALIGN@ \
@FLAG_W_CAST_QUAL@ \
@FLAG_W_WRITE_STRINGS@ \
@FLAG_W_EMPTY_BODY@ \
Modified: trunk/configure.ac
==============================================================================
--- trunk/configure.ac (original)
+++ trunk/configure.ac Mon Sep 14 22:11:32 2015
@@ -1967,6 +1967,15 @@
])
CFLAGS=$safe_CFLAGS
+# On ARM we do not want to pass -Wcast-align as that produces loads
+# of warnings. GCC is just being conservative. See here:
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65459#c4
+if test "X$VGCONF_ARCH_PRI" = "Xarm"; then
+ AC_SUBST([FLAG_W_CAST_ALIGN], [""])
+else
+ AC_SUBST([FLAG_W_CAST_ALIGN], [-Wcast-align])
+fi
+
# does this compiler support -fno-stack-protector ?
AC_MSG_CHECKING([if gcc accepts -fno-stack-protector])
|
|
From: Peter B. <be...@vn...> - 2015-09-14 21:05:58
|
On Mon, 2015-09-14 at 22:31 +0200, Mark Wielaard wrote: > AT_HWCAP: dfp arch_2_05 ic_snoop smt mmu fpu altivec ppc64 ppc32 For divweu, you would need arch_2_06 (ie, power7) defined in AT_HWCAP. Peter |
|
From: Carl E. L. <ce...@us...> - 2015-09-14 20:46:29
|
On Mon, 2015-09-14 at 15:35 -0500, Peter Bergner wrote:
> On Mon, 2015-09-14 at 22:31 +0200, Mark Wielaard wrote:
> > AT_HWCAP: dfp arch_2_05 ic_snoop smt mmu fpu altivec ppc64 ppc32
>
> For divweu, you would need arch_2_06 (ie, power7) defined in AT_HWCAP.
We check that the divweu and divwe instructions in guest_ppc_toIR.c
check allow_VX to verify the platform supports ISA 2.06 or newer.
The vbit test needs to be updated to only issue the test for Power 7 and
newer. I setup valgrind on a Power 6 box and will work on a fix.
Carl Love
|
|
From: Mark W. <mj...@re...> - 2015-09-14 20:46:09
|
On Mon, Sep 14, 2015 at 10:12:59PM +0200, Florian Krohm wrote: > However, I believe we should not ship code that, when compiled, spits > out loads of warnings. That makes a pretty bad impression. > So I'm proposing to not give -Wcast-align when compiling on arm. > > Any objections? No objection. The result clearly works. It looks like gcc is just really conservative in this case. Warning just in case. Thanks, Mark |
|
From: Mark W. <mj...@re...> - 2015-09-14 20:31:32
|
On Mon, Sep 14, 2015 at 09:49:24PM +0200, Florian Krohm wrote: > On 14.09.2015 19:40, Carl E. Love wrote: > Yes. Here is some more evidence that not all 32-bit ppc implementations > support that insn: > https://www.freescale.com/files/product/doc/MPCFPE32B.pdf > That document is from 2005. > > Mark, what does cat /proc/cpuinfo say? cpu : POWER6 (architected), altivec supported clock : 2464.000000MHz revision : 2.3 (pvr 003f 0203) timebase : 512000000 platform : pSeries machine : CHRP IBM,7891-73X AT_HWCAP: dfp arch_2_05 ic_snoop smt mmu fpu altivec ppc64 ppc32 |
|
From: Florian K. <fl...@ei...> - 2015-09-14 20:13:14
|
On 14.09.2015 11:32, Mark Wielaard wrote: > > It was an armv7+. But GCC outputs the warning when the backend defines > STRICT_ALIGNMENT to 1. Which arm does unconditionally. It does support > some unaligned access and there is -munaligned-access (which defaults to > 1 when on armv6+). But That seems to be only for some access or some > instructions. I think this explains why: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65459#c4 > Some unaligned accesses might still use instructions that don't support > unaligned access and so trap into the kernel to adjust those. Which will > slow down stuff a lot. So you still get a warning, just in case... I'm not planning to fix the warnings. Some are false positives, others are easy to fix and then some.... However, I believe we should not ship code that, when compiled, spits out loads of warnings. That makes a pretty bad impression. So I'm proposing to not give -Wcast-align when compiling on arm. Any objections? Florian |
|
From: Florian K. <fl...@ei...> - 2015-09-14 19:49:42
|
On 14.09.2015 19:40, Carl E. Love wrote: > > I checked with Peter on the compiler team and the "divweu" is supported > by ppc32 hardware. The 64-bit dividend is stored in two 32-bit > registers. > > This does seem to be in conflict with the doc that you pointed me at. Yes. Here is some more evidence that not all 32-bit ppc implementations support that insn: https://www.freescale.com/files/product/doc/MPCFPE32B.pdf That document is from 2005. Mark, what does cat /proc/cpuinfo say? Florian |
|
From: <sv...@va...> - 2015-09-14 19:36:37
|
Author: florian
Date: Mon Sep 14 20:36:29 2015
New Revision: 3188
Log:
ppc: The functions dis_dfp_fmt_conv and dis_dfp_exponent_test
should only be executed in case DFP is supported. Add missing
guards.
Modified:
trunk/priv/guest_ppc_toIR.c
Modified: trunk/priv/guest_ppc_toIR.c
==============================================================================
--- trunk/priv/guest_ppc_toIR.c (original)
+++ trunk/priv/guest_ppc_toIR.c Mon Sep 14 20:36:29 2015
@@ -19172,6 +19172,7 @@
case 0x322: // POWER 7 inst, dcffix - DFP convert from fixed
if (!allow_VX)
goto decode_failure;
+ if (!allow_DFP) goto decode_noDFP;
if (dis_dfp_fmt_conv( theInstr ))
goto decode_success;
goto decode_failure;
@@ -19598,6 +19599,7 @@
goto decode_success;
goto decode_failure;
case 0xA2: // dtstexq - DFP Test exponent Quad
+ if (!allow_DFP) goto decode_noDFP;
if (dis_dfp_exponent_test( theInstr ) )
goto decode_success;
goto decode_failure;
|
|
From: Carl E. L. <ce...@us...> - 2015-09-14 17:41:58
|
On Sat, 2015-09-12 at 22:46 +0200, Florian Krohm wrote: > On 12.09.2015 22:10, Mark Wielaard wrote: > > On Sat, 2015-09-12 at 20:42 +0200, Florian Krohm wrote: > >> On 12.09.2015 17:23, Mark Wielaard wrote: > >> > >>> All I can offer you at the moment is the unfiltered output: > >>> > >>> :::::::::::::: > >>> memcheck/tests/vbit-test/vbit-test.stderr.out.unfiltered.out > >>> :::::::::::::: > >>> ==8767== > >>> ==8767== Process terminating with default action of signal 4 (SIGILL) > >>> ==8767== Illegal opcode at address 0x834D26BC > >>> ==8767== at 0x100076F4: valgrind_vex_inject_ir (valgrind.c:85) > >>> ==8767== by 0x100076F4: valgrind_execute_test (valgrind.c:111) > >>> ==8767== by 0x10001D27: test_binary_op (binary.c:461) > >>> ==8767== by 0x10000BCB: main (main.c:135) > >>> > >>> So it crashed at the VALGRIND_VEX_INJECT_IR for some reason. > >>> > >> > >> That would suggest that the injected code is invalid for ppc32. > >> Can you rerun with: > >> > >> Index: memcheck/tests/vbit-test/vbit-test.vgtest > >> =================================================================== > >> --- memcheck/tests/vbit-test/vbit-test.vgtest (revision 15647) > >> +++ memcheck/tests/vbit-test/vbit-test.vgtest (working copy) > >> @@ -1,2 +1,3 @@ > >> prog: vbit-test > >> vgopts: -q > >> +args: -v -v > >> > >> The .out file should tell which IROp is causing it. > > > > :::::::::::::: > > memcheck/tests/vbit-test/vbit-test.stdout.out > > :::::::::::::: > .... > > Testing operator Iop_DivU32E > > > > Ah yes.. > In host_ppc_isel.c around line 1538 a PPCInstr_Div with extended == 1 is > created for tat IROp. > Then in host_ppc_defs.c around line 4082 a divweu is generated for that. > > That seems to be an insn that is only available for power7 and newer. I > do not know that for sure but > http://www-01.ibm.com/support/knowledgecenter/SSGH4D_14.1.0/com.ibm.xlf141.aix.doc/language_ref/divwe.html > says so for divwe (which is for signed extended division). > > I'd say, this is a bug in the powerpc port. Carl, what do you think? I checked with Peter on the compiler team and the "divweu" is supported by ppc32 hardware. The 64-bit dividend is stored in two 32-bit registers. This does seem to be in conflict with the doc that you pointed me at. Unfortunately, I don't have access to a real ppc32 machine to properly test this on the HW. So, at the moment I would say testing the iop Iop_DivU32E which generates the divweu instruction on ppc32 HW should succeed. Peter, do you agree? Carl Love |
|
From: Carl E. L. <ce...@us...> - 2015-09-14 17:37:43
|
On Mon, 2015-09-14 at 11:56 -0500, Peter Bergner wrote:
> On Mon, 2015-09-14 at 09:03 -0700, Carl E. Love wrote:
> On Sat, 2015-09-12 at 20:50 +0200, Florian Krohm wrote:
> >> while looking at the vbit-test failure on ppc32 I noticed that in
> >> guest_ppc_toIR.c all dis_dfp_XYZZY functions are guarded by
> >> if (!allow_DFP) goto decode_noDFP
> >> except the two below. An oversight ?
> >
> > Yes, this does appear to be an oversight as these instructions use an
> > Iop that was created specifically for these instructions. PPC32 does
> > not have DFP support so trying to test the Iop on ppc32 would be an
> > issue.
>
> If by PPC32 you mean 32-bit hardware, then yes I know of no 32-bit
> hardware that supports DFP. OTOH, if by PPC32 you mean 32-bit
> applications, then PPC32 DOES support DFP is that 32-bit application
> is run on a POWER6 or later server hardware. To really determine
> if DFP is supported or not, you really should look at whether the
> "dfp" flag is set in the AT_HWCAP. The same is true of altivec,
> vsx, etc.
The check in Valgrind for allow_DFP that Florian mentioned in his patch
case 0x322: // POWER 7 inst, dcffix - DFP convert from fixed
if (!allow_VX)
goto decode_failure;
+ if (!allow_DFP) goto decode_noDFP;
if (dis_dfp_fmt_conv( theInstr ))
goto decode_success;
is based on checking the underlying hardware caps for
VEX_HWCAPS_PPC64_DFP
Note, Valgrind only checks for this if the machine is either ppc64 big
endian or ppc64 little endian.
So, in this case the two instructions that he noted need to be protected
with the statement "if (!allow_DFP) goto decode_noDFP;" to ensure the
underlying hardware does not try to issue the DFP instruction.
Carl Love
|
|
From: Peter B. <be...@vn...> - 2015-09-14 17:28:08
|
On Mon, 2015-09-14 at 09:03 -0700, Carl E. Love wrote: On Sat, 2015-09-12 at 20:50 +0200, Florian Krohm wrote: >> while looking at the vbit-test failure on ppc32 I noticed that in >> guest_ppc_toIR.c all dis_dfp_XYZZY functions are guarded by >> if (!allow_DFP) goto decode_noDFP >> except the two below. An oversight ? > > Yes, this does appear to be an oversight as these instructions use an > Iop that was created specifically for these instructions. PPC32 does > not have DFP support so trying to test the Iop on ppc32 would be an > issue. If by PPC32 you mean 32-bit hardware, then yes I know of no 32-bit hardware that supports DFP. OTOH, if by PPC32 you mean 32-bit applications, then PPC32 DOES support DFP is that 32-bit application is run on a POWER6 or later server hardware. To really determine if DFP is supported or not, you really should look at whether the "dfp" flag is set in the AT_HWCAP. The same is true of altivec, vsx, etc. [bergner@igoo ~]$ LD_SHOW_AUXV=1 /bin/true | grep AT_HWCAP AT_HWCAP: vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32 Peter |
|
From: Carl E. L. <ce...@us...> - 2015-09-14 16:03:25
|
On Sat, 2015-09-12 at 20:50 +0200, Florian Krohm wrote:
> Carl,
>
> while looking at the vbit-test failure on ppc32 I noticed that in
> guest_ppc_toIR.c all dis_dfp_XYZZY functions are guarded by
> if (!allow_DFP) goto decode_noDFP
> except the two below. An oversight ?
Florian:
Yes, this does appear to be an oversight as these instructions use an
Iop that was created specifically for these instructions. PPC32 does
not have DFP support so trying to test the Iop on ppc32 would be an
issue.
Carl Love
> Florian
>
>
> Index: VEX/priv/guest_ppc_toIR.c
> ===================================================================
> --- VEX/priv/guest_ppc_toIR.c (revision 3187)
> +++ VEX/priv/guest_ppc_toIR.c (working copy)
> @@ -19172,6 +19172,7 @@
> case 0x322: // POWER 7 inst, dcffix - DFP convert from fixed
> if (!allow_VX)
> goto decode_failure;
> + if (!allow_DFP) goto decode_noDFP;
> if (dis_dfp_fmt_conv( theInstr ))
> goto decode_success;
> goto decode_failure;
> @@ -19598,6 +19599,7 @@
> goto decode_success;
> goto decode_failure;
> case 0xA2: // dtstexq - DFP Test exponent Quad
> + if (!allow_DFP) goto decode_noDFP;
> if (dis_dfp_exponent_test( theInstr ) )
> goto decode_success;
> goto decode_failure;
>
|
|
From: Marcin S. <mar...@in...> - 2015-09-14 12:43:39
|
From: Marcin Ślusarz <mar...@in...>
They can be used to validate application assumptions about addressability
and definedness for long pieces of memory without using ADDRESSABLE/DEFINED
variants for each byte in a region.
For libpmemobj, we want to validate whether whole memory pool immediately
after create and load is in only two states: defined or unaddressable.
Pools can be huge and in the beginning they are mostly empty, so to
validate free chunks without CHECK_MEM_IS_UNADDRESSABLE we have to call
CHECK_MEM_IS_ADDRESSABLE for *each* free byte, which is *very* slow.
CHECK_MEM_IS_UNDEFINED is not as important for performance, but
I implemented it for completeness.
---
memcheck/docs/mc-manual.xml | 10 ++++++++++
memcheck/mc_include.h | 2 ++
memcheck/mc_main.c | 31 +++++++++++++++++++++++++++++++
memcheck/memcheck.h | 18 ++++++++++++++++++
memcheck/tests/addressable.c | 33 +++++++++++++++++++++++++++++++++
memcheck/tests/addressable.stderr.exp | 30 ++++++++++++++++++++++++------
memcheck/tests/addressable.stdout.exp | 2 ++
7 files changed, 120 insertions(+), 6 deletions(-)
diff --git memcheck/docs/mc-manual.xml memcheck/docs/mc-manual.xml
index b54b721..6a21ea6 100644
--- memcheck/docs/mc-manual.xml
+++ memcheck/docs/mc-manual.xml
@@ -2118,6 +2118,16 @@ arguments.</para>
</listitem>
<listitem>
+ <para><varname>VALGRIND_CHECK_MEM_IS_UNADDRESSABLE</varname> and
+ <varname>VALGRIND_CHECK_MEM_IS_UNDEFINED</varname>: check immediately
+ whether or not the given address range has the relevant property.
+ Returns zero if the relevant property holds; otherwise,
+ the returned value is the address of the first byte for which the
+ property is not true. Always returns 0 when not run on
+ Valgrind.</para>
+ </listitem>
+
+ <listitem>
<para><varname>VALGRIND_CHECK_VALUE_IS_DEFINED</varname>: a quick and easy
way to find out whether Valgrind thinks a particular value
(lvalue, to be precise) is addressable and defined. Prints an error
diff --git memcheck/mc_include.h memcheck/mc_include.h
index 663cdca..1f4ebcd 100644
--- memcheck/mc_include.h
+++ memcheck/mc_include.h
@@ -277,6 +277,8 @@ enum {
MCPE_IS_MEM_DEFINED_LOOP,
MCPE_IS_MEM_DEFINED_COMPREHENSIVE,
MCPE_IS_MEM_DEFINED_COMPREHENSIVE_LOOP,
+ MCPE_IS_MEM_UNDEFINED,
+ MCPE_IS_MEM_UNDEFINED_LOOP,
MCPE_IS_DEFINED_ASCIIZ,
MCPE_IS_DEFINED_ASCIIZ_LOOP,
MCPE_FIND_CHUNK_FOR_OLD,
diff --git memcheck/mc_main.c memcheck/mc_main.c
index 65fdfcb..4f21472 100644
--- memcheck/mc_main.c
+++ memcheck/mc_main.c
@@ -3792,6 +3792,25 @@ static Bool is_mem_addressable ( Addr a, SizeT len,
return True;
}
+static Bool is_mem_undefined ( Addr a, SizeT len,
+ /*OUT*/Addr* bad_addr )
+{
+ SizeT i;
+ UWord vabits2;
+
+ PROF_EVENT(MCPE_IS_MEM_UNDEFINED);
+ for (i = 0; i < len; i++) {
+ PROF_EVENT(MCPE_IS_MEM_UNDEFINED_LOOP);
+ vabits2 = get_vabits2(a);
+ if (VA_BITS2_UNDEFINED != vabits2) {
+ if (bad_addr != NULL) *bad_addr = a;
+ return False;
+ }
+ a++;
+ }
+ return True;
+}
+
static MC_ReadResult is_mem_defined ( Addr a, SizeT len,
/*OUT*/Addr* bad_addr,
/*OUT*/UInt* otag )
@@ -6561,6 +6580,18 @@ static Bool mc_handle_client_request ( ThreadId tid, UWord* arg, UWord* ret )
break;
}
+ case VG_USERREQ__CHECK_MEM_IS_UNADDRESSABLE: {
+ Bool ok = MC_(check_mem_is_noaccess) ( arg[1], arg[2], &bad_addr );
+ *ret = ok ? (UWord)NULL : bad_addr;
+ break;
+ }
+
+ case VG_USERREQ__CHECK_MEM_IS_UNDEFINED: {
+ Bool ok = is_mem_undefined( arg[1], arg[2], &bad_addr );
+ *ret = ok ? (UWord)NULL : bad_addr;
+ break;
+ }
+
case VG_USERREQ__CHECK_MEM_IS_DEFINED: {
Bool errorV = False;
Addr bad_addrV = 0;
diff --git memcheck/memcheck.h memcheck/memcheck.h
index 811930e..7514071 100644
--- memcheck/memcheck.h
+++ memcheck/memcheck.h
@@ -99,6 +99,9 @@ typedef
VG_USERREQ__ENABLE_ADDR_ERROR_REPORTING_IN_RANGE,
VG_USERREQ__DISABLE_ADDR_ERROR_REPORTING_IN_RANGE,
+ VG_USERREQ__CHECK_MEM_IS_UNADDRESSABLE,
+ VG_USERREQ__CHECK_MEM_IS_UNDEFINED,
+
/* This is just for memcheck's internal use - don't use it */
_VG_USERREQ__MEMCHECK_RECORD_OVERLAP_ERROR
= VG_USERREQ_TOOL_BASE('M','C') + 256
@@ -184,6 +187,21 @@ typedef
(volatile unsigned char *)&(__lvalue), \
(unsigned long)(sizeof (__lvalue)))
+/* Check that memory at _qzz_addr is unaddressable for _qzz_len bytes.
+ If any byte in this range is addressable, Valgrind returns the
+ address of the first offending byte. Otherwise it returns zero. */
+#define VALGRIND_CHECK_MEM_IS_UNADDRESSABLE(_qzz_addr,_qzz_len) \
+ VALGRIND_DO_CLIENT_REQUEST_EXPR(0, \
+ VG_USERREQ__CHECK_MEM_IS_UNADDRESSABLE,\
+ (_qzz_addr), (_qzz_len), 0, 0, 0)
+
+/* Check that memory at _qzz_addr is undefined for _qzz_len bytes. If any
+ byte in this range is defined or unaddressable, Valgrind returns the
+ address of the first offending byte. Otherwise it returns zero. */
+#define VALGRIND_CHECK_MEM_IS_UNDEFINED(_qzz_addr,_qzz_len) \
+ VALGRIND_DO_CLIENT_REQUEST_EXPR(0, \
+ VG_USERREQ__CHECK_MEM_IS_UNDEFINED, \
+ (_qzz_addr), (_qzz_len), 0, 0, 0)
/* Do a full memory leak check (like --leak-check=full) mid-execution. */
#define VALGRIND_DO_LEAK_CHECK \
diff --git memcheck/tests/addressable.c memcheck/tests/addressable.c
index 5f3c2e1..e3240f5 100644
--- memcheck/tests/addressable.c
+++ memcheck/tests/addressable.c
@@ -91,6 +91,37 @@ static void test5()
(void) VALGRIND_CHECK_MEM_IS_DEFINED(m+20, 10); /* BAD */
}
+/* Case 6 - test CHECK_MEM_IS_UNDEFINED */
+static void test6()
+{
+ char *m = mm(0, pgsz * 5, PROT_READ|PROT_WRITE);
+
+ (void) VALGRIND_MAKE_MEM_UNDEFINED(m, pgsz*5);
+ if (VALGRIND_CHECK_MEM_IS_UNDEFINED(m, pgsz*5) != NULL)
+ exit(61);
+
+ memset(m, 'x', 10);
+ if (VALGRIND_CHECK_MEM_IS_UNDEFINED(m, 10) != m)
+ exit(62);
+ if (VALGRIND_CHECK_MEM_IS_UNDEFINED(m+10, 10) != NULL)
+ exit(63);
+}
+
+/* Case 7 - test CHECK_MEM_IS_UNADDRESSABLE */
+static void test7()
+{
+ char *m = mm(0, pgsz * 5, PROT_READ|PROT_WRITE);
+
+ VALGRIND_CHECK_MEM_IS_ADDRESSABLE(m, pgsz * 5);
+ if (VALGRIND_CHECK_MEM_IS_UNADDRESSABLE(m, pgsz * 5) != m)
+ exit(71);
+
+ munmap(m, pgsz * 5);
+
+ if (VALGRIND_CHECK_MEM_IS_UNADDRESSABLE(m, pgsz * 5) != NULL)
+ exit(72);
+}
+
static struct test {
void (*test)(void);
int faults;
@@ -100,6 +131,8 @@ static struct test {
{ test3, 0 },
{ test4, 1 },
{ test5, 0 },
+ { test6, 0 },
+ { test7, 0 },
};
static const int n_tests = sizeof(tests)/sizeof(*tests);
diff --git memcheck/tests/addressable.stderr.exp memcheck/tests/addressable.stderr.exp
index 8fbd952..107b644 100644
--- memcheck/tests/addressable.stderr.exp
+++ memcheck/tests/addressable.stderr.exp
@@ -10,19 +10,19 @@ 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)
- by 0x........: main (addressable.c:125)
+ by 0x........: main (addressable.c:158)
Address 0x........ is not stack'd, malloc'd or (recently) free'd
Invalid write of size 1
at 0x........: test2 (addressable.c:51)
- by 0x........: main (addressable.c:125)
+ by 0x........: main (addressable.c:158)
Address 0x........ is not stack'd, malloc'd or (recently) free'd
Process terminating with default action of signal N (SIGSEGV or SIGBUS)
Bad memory (SIGSEGV or SIGBUS) at address 0x........
at 0x........: test2 (addressable.c:51)
- by 0x........: main (addressable.c:125)
+ by 0x........: main (addressable.c:158)
If you believe this happened as a result of a stack
overflow in your program's main thread (unlikely but
possible), you can try to increase the size of the
@@ -50,7 +50,7 @@ ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Process terminating with default action of signal N (SIGSEGV or SIGBUS)
Bad memory (SIGSEGV or SIGBUS) at address 0x........
at 0x........: test4 (addressable.c:74)
- by 0x........: main (addressable.c:125)
+ by 0x........: main (addressable.c:158)
HEAP SUMMARY:
in use at exit: ... bytes in ... blocks
@@ -62,12 +62,12 @@ For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Uninitialised byte(s) found during client check request
at 0x........: test5 (addressable.c:85)
- by 0x........: main (addressable.c:125)
+ by 0x........: main (addressable.c:158)
Address 0x........ is in a rw- anonymous segment
Uninitialised byte(s) found during client check request
at 0x........: test5 (addressable.c:91)
- by 0x........: main (addressable.c:125)
+ by 0x........: main (addressable.c:158)
Address 0x........ is in a r-- anonymous segment
@@ -89,3 +89,21 @@ For a detailed leak analysis, rerun with: --leak-check=full
For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+
+HEAP SUMMARY:
+ in use at exit: ... bytes in ... blocks
+ total heap usage: ... allocs, ... frees, ... bytes allocated
+
+For a detailed leak analysis, rerun with: --leak-check=full
+
+For counts of detected and suppressed errors, rerun with: -v
+ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+
+HEAP SUMMARY:
+ in use at exit: ... bytes in ... blocks
+ total heap usage: ... allocs, ... frees, ... bytes allocated
+
+For a detailed leak analysis, rerun with: --leak-check=full
+
+For counts of detected and suppressed errors, rerun with: -v
+ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
diff --git memcheck/tests/addressable.stdout.exp memcheck/tests/addressable.stdout.exp
index f72368e..b47a782 100644
--- memcheck/tests/addressable.stdout.exp
+++ memcheck/tests/addressable.stdout.exp
@@ -3,3 +3,5 @@ Test 2: PASS
Test 3: PASS
Test 4: PASS
Test 5: PASS
+Test 6: PASS
+Test 7: PASS
--
2.5.0
--------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
|
|
From: Marcin S. <mar...@in...> - 2015-09-14 12:43:37
|
From: Marcin Ślusarz <mar...@in...>
The error looks like this:
"Memcheck: mc_malloc_wrappers.c:244 (in_block_list): Assertion 'found_mc == mc' failed.
host stacktrace:
at 0x38083468: show_sched_status_wrk (m_libcassert.c:343)
by 0x38083584: report_and_quit (m_libcassert.c:415)
by 0x38083711: vgPlain_assert_fail (m_libcassert.c:481)
by 0x380504D3: in_block_list (mc_malloc_wrappers.c:244)
by 0x3805052C: live_block (mc_malloc_wrappers.c:257)
by 0x38050674: vgMemCheck_allocated_at (mc_malloc_wrappers.c:273)
by 0x38079DDE: describe_addr (mc_errors.c:1072)
by 0x3807B393: vgMemCheck_update_Error_extra (mc_errors.c:1141)
by 0x3807F55A: vgPlain_maybe_record_error (m_errormgr.c:813)
by 0x3807A95A: vgMemCheck_record_address_error (mc_errors.c:760)"
---
NEWS | 2 ++
memcheck/mc_malloc_wrappers.c | 14 +++++++++++
memcheck/tests/mempool2.c | 12 ++++++++++
memcheck/tests/mempool2.stderr.exp | 49 ++++++++++++++++++++++++--------------
4 files changed, 59 insertions(+), 18 deletions(-)
diff --git NEWS NEWS
index 7119ab8..88012e9 100644
--- NEWS
+++ NEWS
@@ -375,6 +375,8 @@ where XXXXXX is the bug number as listed below.
350811 Remove reference to --db-attach which has been removed.
350813 Memcheck/x86: enable handwritten assembly helpers for x86/Solaris too
350854 hard-to-understand code in VG_(load_ELF)()
+350928 Fix assertion failure (in_block_list: found_mc == mc) when user allocates
+ in recently freed space and touches noaccess space close to it.
351140 arm64 syscalls setuid (146) and setresgid (149) not implemented
351386 Solaris: Cannot run ld.so.1 under Valgrind
351474 Fix VG_(iseqsigset) as obvious
diff --git memcheck/mc_malloc_wrappers.c memcheck/mc_malloc_wrappers.c
index 08fcc2d..469d0bd 100644
--- memcheck/mc_malloc_wrappers.c
+++ memcheck/mc_malloc_wrappers.c
@@ -241,6 +241,20 @@ static Bool in_block_list (const VgHashTable *block_list, MC_Chunk* mc)
if (found_mc->szB != mc->szB
|| found_mc->allockind != mc->allockind)
return False;
+
+ /* If a user freed and allocated again in the same spot (through
+ * VALGRIND_MEMPOOL_FREE/ALLOC), we might arrive here with
+ * a dead chunk which has the same address as an alive one. */
+ if (mc->allockind == MC_AllocCustom && found_mc != mc) {
+ const int l = (mc->szB >= MC_(clo_freelist_big_blocks) ? 0 : 1);
+ MC_Chunk *c = freed_list_start[l];
+ do {
+ if (c == mc)
+ return False;
+ c = c->next;
+ } while (c);
+ }
+
tl_assert (found_mc == mc);
return True;
} else
diff --git memcheck/tests/mempool2.c memcheck/tests/mempool2.c
index 8fa3d5c..3bdad63 100644
--- memcheck/tests/mempool2.c
+++ memcheck/tests/mempool2.c
@@ -183,6 +183,18 @@ void test(void)
// claim res is used, so gcc can't nuke this all
__asm__ __volatile__("" : : "r"(res));
+ {
+ char tmp[100];
+ VALGRIND_CREATE_MEMPOOL(tmp, 0, 0);
+ VALGRIND_MEMPOOL_ALLOC(tmp, tmp + 8, 16);
+ VALGRIND_MEMPOOL_FREE(tmp, tmp + 8);
+ VALGRIND_MEMPOOL_ALLOC(tmp, tmp + 8, 16);
+ VALGRIND_MAKE_MEM_NOACCESS(tmp, 8);
+ fprintf(stderr,
+ "\n------ write to noaccess space close to reallocated object ------\n\n");
+ tmp[7] = 0x66;
+ }
+
fprintf(stderr,
"\n------ done ------\n\n");
pop(p1, 0);
diff --git memcheck/tests/mempool2.stderr.exp memcheck/tests/mempool2.stderr.exp
index 16b1f38..b374e44 100644
--- memcheck/tests/mempool2.stderr.exp
+++ memcheck/tests/mempool2.stderr.exp
@@ -3,57 +3,57 @@
Invalid read of size 1
at 0x........: test (mempool2.c:135)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Address 0x........ is 1 bytes before a block of size 10 client-defined
at 0x........: allocate (mempool2.c:108)
by 0x........: test (mempool2.c:130)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Invalid read of size 1
at 0x........: test (mempool2.c:136)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Address 0x........ is 0 bytes after a block of size 10 client-defined
at 0x........: allocate (mempool2.c:108)
by 0x........: test (mempool2.c:130)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
------ out of range reads in mmap-backed pool ------
Invalid read of size 1
at 0x........: test (mempool2.c:140)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Address 0x........ is 1 bytes before a block of size 20 client-defined
at 0x........: allocate (mempool2.c:108)
by 0x........: test (mempool2.c:131)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Invalid read of size 1
at 0x........: test (mempool2.c:141)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Address 0x........ is 0 bytes after a block of size 20 client-defined
at 0x........: allocate (mempool2.c:108)
by 0x........: test (mempool2.c:131)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
------ read free in malloc-backed pool ------
Illegal memory pool address
at 0x........: test (mempool2.c:145)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Address 0x........ is 0 bytes inside a block of size 32 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: make_pool (mempool2.c:46)
by 0x........: test (mempool2.c:122)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
------ read free in mmap-backed pool ------
Illegal memory pool address
at 0x........: test (mempool2.c:150)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Address 0x........ is in a rwx anonymous segment
@@ -61,19 +61,19 @@ Illegal memory pool address
Illegal memory pool address
at 0x........: test (mempool2.c:155)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Address 0x........ is 0 bytes inside a block of size 32 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: make_pool (mempool2.c:46)
by 0x........: test (mempool2.c:122)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
------ double free in mmap-backed pool ------
Illegal memory pool address
at 0x........: test (mempool2.c:159)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Address 0x........ is in a rwx anonymous segment
@@ -81,17 +81,30 @@ Illegal memory pool address
Invalid read of size 1
at 0x........: test (mempool2.c:178)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Address 0x........ is 1 bytes before a block of size 10 client-defined
at 0x........: test (mempool2.c:171)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Invalid read of size 1
at 0x........: test (mempool2.c:179)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
Address 0x........ is 0 bytes after a block of size 10 client-defined
at 0x........: test (mempool2.c:171)
- by 0x........: main (mempool2.c:196)
+ by 0x........: main (mempool2.c:208)
+
+
+------ write to noaccess space close to reallocated object ------
+
+Invalid write of size 1
+ at 0x........: test (mempool2.c:195)
+ by 0x........: main (mempool2.c:208)
+ Address 0x........ is 1 bytes before a block of size 16 free'd
+ at 0x........: test (mempool2.c:190)
+ by 0x........: main (mempool2.c:208)
+ Block was alloc'd at
+ at 0x........: test (mempool2.c:189)
+ by 0x........: main (mempool2.c:208)
------ done ------
--
2.5.0
--------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
|
|
From: Mark W. <mj...@re...> - 2015-09-14 09:32:30
|
On Mon, 2015-09-14 at 10:25 +0200, Florian Krohm wrote: > '-Wcast-align' > Warn whenever a pointer is cast such that the required alignment of > the target is increased. For example, warn if a 'char *' is cast > to an 'int *' on machines where integers can only be accessed at > two- or four-byte boundaries. > > So the warning is machine dependent. > From this page > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html > I gather that unaligned access is OK for ARMv6 and newer. > http://valgrind.org/info/platforms.html says we support ARMv7 so we > should be OK and can ignore those warnings. Perhaps your arm build was > on something older ? It was an armv7+. But GCC outputs the warning when the backend defines STRICT_ALIGNMENT to 1. Which arm does unconditionally. It does support some unaligned access and there is -munaligned-access (which defaults to 1 when on armv6+). But That seems to be only for some access or some instructions. I think this explains why: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65459#c4 Some unaligned accesses might still use instructions that don't support unaligned access and so trap into the kernel to adjust those. Which will slow down stuff a lot. So you still get a warning, just in case... Cheers, Mark |
|
From: Florian K. <fl...@ei...> - 2015-09-14 08:25:25
|
Hi Mark,
>> I did not do anything about the
>> cast-align warnings as that is a warning specific to your compile
>> environment (stock valgrind does not compile with -Wcast-align).
>
> Are you sure?
no :)
> Makefile.all.am adds -Wcast-align to AM_CFLAGS_BASE.
Right you are. I had incorrectly concluded from the absence of any
cast-align warnings on other platforms, that you had somehow added that
option. But as gcc docs point out:
'-Wcast-align'
Warn whenever a pointer is cast such that the required alignment of
the target is increased. For example, warn if a 'char *' is cast
to an 'int *' on machines where integers can only be accessed at
two- or four-byte boundaries.
So the warning is machine dependent.
>From this page
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html
I gather that unaligned access is OK for ARMv6 and newer.
http://valgrind.org/info/platforms.html says we support ARMv7 so we
should be OK and can ignore those warnings. Perhaps your arm build was
on something older ?
Florian
|