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
(1) |
|
2
(19) |
3
(17) |
4
(15) |
5
(20) |
6
(29) |
7
(13) |
8
(16) |
|
9
(20) |
10
(5) |
11
(10) |
12
(17) |
13
(17) |
14
(22) |
15
(8) |
|
16
(4) |
17
(15) |
18
(7) |
19
(14) |
20
(16) |
21
(18) |
22
(9) |
|
23
(2) |
24
(12) |
25
(3) |
26
(3) |
27
(20) |
28
(9) |
29
(4) |
|
30
(3) |
31
(4) |
|
|
|
|
|
|
From: John R. <jr...@bi...> - 2012-12-14 22:56:59
|
> Using the patch to valgrind-3.8.1 on a machine with 32GB RAM and 80GB swap, Sorry; make that 16GB RAM and 80GB swap. -- |
|
From: John R. <jr...@bi...> - 2012-12-14 22:48:06
|
> Yes, that is as expected. By default V will only use 32GB of memory,
> and that is divided more or less evenly between the application and
> Valgrind itself. Hence your app will not be able to use more than
> 16GB.
>
> The patch below doubles those limits, so you can go up to 32GB.
> Give it a try. I would like to commit it, but it needs testing.
Using the patch to valgrind-3.8.1 on a machine with 32GB RAM and 80GB swap,
I can mmap 0x7f0000000 bytes (32GiB - 256MiB) to PROT_NONE,
but not 0x800000000 bytes (32GiB): [running Fedora 18-Final-TC2]
-----
$ /usr/local/valgrind-svn/bin/valgrind ./mmap-big 0x7f0000000
==15519== Memcheck, a memory error detector
==15519== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==15519== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
==15519== Command: ./mmap-big 0x7f0000000
==15519==
==15519== Warning: set address range perms: large range [0x805ce6000, 0xff5ce6000) (noaccess)
34091302912(0x7f0000000) bytes at 0x805ce6000
-----
When not running under valgrind, I can get almost to 128TiB:
-----
$ ./mmap-big 0x800000000000
140737488355328{0x800000000000) bytes failed.
$ ./mmap-big 0x7f0000000000
139637976727552(0x7f0000000000) bytes at 0x76dad8c000
$
-----
--
|
|
From: Petar J. <mip...@gm...> - 2012-12-14 14:21:26
|
Bug has been created for this issue: https://bugs.kde.org/show_bug.cgi?id=311690 Until it is fixed, one of the workarounds could be to avoid pthread_spinlock interception for Helgrind and DRD for MIPS32. Let me know if anyone disagrees. Petar Index: helgrind/hg_intercepts.c =================================================================== --- helgrind/hg_intercepts.c (revision 13176) +++ helgrind/hg_intercepts.c (working copy) @@ -1095,7 +1095,7 @@ /*--- pthread_spinlock_t functions ---*/ /*----------------------------------------------------------------*/ -#if defined(HAVE_PTHREAD_SPIN_LOCK) +#if defined(HAVE_PTHREAD_SPIN_LOCK) && !defined(VGP_mips32_linux) /* Handled: pthread_spin_init pthread_spin_destroy pthread_spin_lock pthread_spin_trylock Index: drd/drd_pthread_intercepts.c =================================================================== --- drd/drd_pthread_intercepts.c (revision 13176) +++ drd/drd_pthread_intercepts.c (working copy) @@ -803,7 +803,7 @@ PTH_FUNCS(int, pthreadZucondZubroadcast, pthread_cond_broadcast_intercept, (pthread_cond_t* cond), (cond)); -#if defined(HAVE_PTHREAD_SPIN_LOCK) +#if defined(HAVE_PTHREAD_SPIN_LOCK) && !defined(VGP_mips32_linux) static __always_inline int pthread_spin_init_intercept(pthread_spinlock_t *spinlock, int pshared) { |
|
From: Dave G. <go...@mc...> - 2012-12-14 12:57:39
|
On Dec 14, 2012, at 9:50 PM GMT+09:00, Julian Seward wrote: >> On Fri, 2012-12-14 at 21:32 +0900, Dave Goodell wrote: >>> Thanks for testing this, Rich. >>> >>> Julian (or someone), would you please apply this patch at your >>> convenience? Or would a bugzilla be preferred at this stage? >> >> I already bothered him on irc. It is in now r13180. > > Oh, I should have mentioned here that I committed it. Sorry. And I should have noticed the commit email fly past (I thought I looked, but must have missed it, since it's plainly there). Sorry for the noise. -Dave |
|
From: Julian S. <js...@ac...> - 2012-12-14 12:57:21
|
On Friday, December 14, 2012, Roland Mainz wrote: > WIthout looking at the sources myself... > ... would it be hard to make this kind of change a command-line option ? Difficult to do without taking a performance hit in Memcheck. How much memory do you need? What is currently needed is someone to verify that, with this patch, the system can be run up to 32G (user) / 64G (total) without problems. I only have a machine with 8GB memory, so I can't test it myself. J |
|
From: <sv...@va...> - 2012-12-14 12:51:16
|
sewardj 2012-12-14 12:51:08 +0000 (Fri, 14 Dec 2012)
New Revision: 13181
Log:
Add a detailed comment re the situation with checking definedness of
addresses in guarded loads, stores and dirty helpers that access
memory. Fall back to a simpler situation as documented in the
comment, possibly on a temporary basis.
Modified files:
branches/COMEM/memcheck/mc_translate.c
Modified: branches/COMEM/memcheck/mc_translate.c (+84 -43)
===================================================================
--- branches/COMEM/memcheck/mc_translate.c 2012-12-14 10:30:57 +00:00 (rev 13180)
+++ branches/COMEM/memcheck/mc_translate.c 2012-12-14 12:51:08 +00:00 (rev 13181)
@@ -43,6 +43,56 @@
#include "mc_include.h"
+/* Comments re guarded loads and stores, and conditional dirty calls
+ that access memory, JRS 2012-Dec-14, for branches/COMEM, r13180.
+
+ Currently Memcheck generates code that checks the definedness of
+ addresses in such cases, regardless of the what the guard value is
+ (at runtime). This could potentially lead to false positives if we
+ ever construct IR in which a guarded memory access happens, and the
+ address is undefined when the guard is false. However, at the
+ moment I am not aware of any situations where such IR is generated.
+
+ The obvious thing to do is generate conditionalised checking code
+ in such cases. However:
+
+ * it's more complex to verify
+
+ * it is cheaper to always do the check -- basically a check if
+ the shadow value is nonzero, and conditional call to report
+ an error if so -- than it is to conditionalise the check.
+
+ * currently the implementation is incomplete. complainIfUndefined
+ can correctly conditionalise the check and complaint as per its
+ third argument. However, the part of it that then sets the
+ shadow to 'defined' (see comments at the top of said fn) ignores
+ the guard.
+
+ Therefore, removing this functionality in r13181 until we know we
+ need it. To reinstate, do the following:
+
+ * back out r13181 (which also adds this comment)
+
+ * undo (== reinstate the non-NULL 3rd args) in the following two
+ chunks, which were removed in r13142. These are the only two
+ places where complainIfUndefined is actually used with a guard.
+
+ // First, emit a definedness test for the address. This also sets
+ // the address (shadow) to 'defined' following the test.
+ - complainIfUndefined( mce, addr, guard );
+ + complainIfUndefined( mce, addr, NULL );
+
+ and
+
+ IRType tyAddr;
+ tl_assert(d->mAddr);
+ - complainIfUndefined(mce, d->mAddr, d->guard);
+ + complainIfUndefined(mce, d->mAddr, NULL);
+
+ * fix complainIfUndefined to conditionalise setting the shadow temp
+ to 'defined', as described above.
+*/
+
/* FIXMEs JRS 2011-June-16.
Check the interpretation for vector narrowing and widening ops,
@@ -1103,7 +1153,7 @@
conditionally, as defined by |guard|. If |guard| is NULL then it
is assumed to be always-true.
*/
-static void complainIfUndefined ( MCEnv* mce, IRAtom* atom, IRExpr *guard )
+static void complainIfUndefined ( MCEnv* mce, IRAtom* atom )
{
IRAtom* vatom;
IRType ty;
@@ -1236,15 +1286,6 @@
VG_(fnptr_to_fnentry)( fn ), args );
di->guard = cond;
- /* If the complaint is to be issued under a guard condition, AND
- that into the guard condition for the helper call. */
- if (guard) {
- IRAtom *g1 = assignNew('V', mce, Ity_I32, unop(Iop_1Uto32, di->guard));
- IRAtom *g2 = assignNew('V', mce, Ity_I32, unop(Iop_1Uto32, guard));
- IRAtom *e = assignNew('V', mce, Ity_I32, binop(Iop_And32, g1, g2));
- di->guard = assignNew('V', mce, Ity_I1, unop(Iop_32to1, e));
- }
-
setHelperAnns( mce, di );
stmt( 'V', mce, IRStmt_Dirty(di));
@@ -1376,7 +1417,7 @@
arrSize = descr->nElems * sizeofIRType(ty);
tl_assert(ty != Ity_I1);
tl_assert(isOriginalAtom(mce,ix));
- complainIfUndefined(mce, ix, NULL);
+ complainIfUndefined(mce, ix);
if (isAlwaysDefd(mce, descr->base, arrSize)) {
/* later: no ... */
/* emit code to emit a complaint if any of the vbits are 1. */
@@ -1425,7 +1466,7 @@
Int arrSize = descr->nElems * sizeofIRType(ty);
tl_assert(ty != Ity_I1);
tl_assert(isOriginalAtom(mce,ix));
- complainIfUndefined(mce, ix, NULL);
+ complainIfUndefined(mce, ix);
if (isAlwaysDefd(mce, descr->base, arrSize)) {
/* Always defined, return all zeroes of the relevant type */
return definedOfType(tyS);
@@ -2571,15 +2612,15 @@
/* IRRoundingModeDFP(I32) x I8 x D128 -> D128 */
return mkLazy3(mce, Ity_I128, vatom1, vatom2, vatom3);
case Iop_ExtractV128:
- complainIfUndefined(mce, atom3, NULL);
+ complainIfUndefined(mce, atom3);
return assignNew('V', mce, Ity_V128, triop(op, vatom1, vatom2, atom3));
case Iop_Extract64:
- complainIfUndefined(mce, atom3, NULL);
+ complainIfUndefined(mce, atom3);
return assignNew('V', mce, Ity_I64, triop(op, vatom1, vatom2, atom3));
case Iop_SetElem8x8:
case Iop_SetElem16x4:
case Iop_SetElem32x2:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_I64, triop(op, vatom1, atom2, vatom3));
default:
ppIROp(op);
@@ -2646,7 +2687,7 @@
case Iop_ShlN32x2:
case Iop_ShlN8x8:
/* Same scheme as with all other shifts. */
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_I64, binop(op, vatom1, atom2));
case Iop_QNarrowBin32Sto16Sx4:
@@ -2729,25 +2770,25 @@
case Iop_QShlN8Sx8:
case Iop_QShlN8x8:
case Iop_QSalN8x8:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return mkPCast8x8(mce, vatom1);
case Iop_QShlN16Sx4:
case Iop_QShlN16x4:
case Iop_QSalN16x4:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return mkPCast16x4(mce, vatom1);
case Iop_QShlN32Sx2:
case Iop_QShlN32x2:
case Iop_QSalN32x2:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return mkPCast32x2(mce, vatom1);
case Iop_QShlN64Sx1:
case Iop_QShlN64x1:
case Iop_QSalN64x1:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return mkPCast32x2(mce, vatom1);
case Iop_PwMax32Sx2:
@@ -2844,13 +2885,13 @@
return assignNew('V', mce, Ity_I64, binop(op, vatom1, vatom2));
case Iop_GetElem8x8:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_I8, binop(op, vatom1, atom2));
case Iop_GetElem16x4:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_I16, binop(op, vatom1, atom2));
case Iop_GetElem32x2:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_I32, binop(op, vatom1, atom2));
/* Perm8x8: rearrange values in left arg using steering values
@@ -2880,7 +2921,7 @@
/* Same scheme as with all other shifts. Note: 22 Oct 05:
this is wrong now, scalar shifts are done properly lazily.
Vector shifts should be fixed too. */
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_V128, binop(op, vatom1, atom2));
/* V x V shifts/rotates are done using the standard lazy scheme. */
@@ -2927,14 +2968,14 @@
case Iop_F32ToFixed32Sx4_RZ:
case Iop_Fixed32UToF32x4_RN:
case Iop_Fixed32SToF32x4_RN:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return mkPCast32x4(mce, vatom1);
case Iop_F32ToFixed32Ux2_RZ:
case Iop_F32ToFixed32Sx2_RZ:
case Iop_Fixed32UToF32x2_RN:
case Iop_Fixed32SToF32x2_RN:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return mkPCast32x2(mce, vatom1);
case Iop_QSub8Ux16:
@@ -3091,25 +3132,25 @@
case Iop_QShlN8Sx16:
case Iop_QShlN8x16:
case Iop_QSalN8x16:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return mkPCast8x16(mce, vatom1);
case Iop_QShlN16Sx8:
case Iop_QShlN16x8:
case Iop_QSalN16x8:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return mkPCast16x8(mce, vatom1);
case Iop_QShlN32Sx4:
case Iop_QShlN32x4:
case Iop_QSalN32x4:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return mkPCast32x4(mce, vatom1);
case Iop_QShlN64Sx2:
case Iop_QShlN64x2:
case Iop_QSalN64x2:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return mkPCast32x4(mce, vatom1);
case Iop_Mull32Sx2:
@@ -3172,16 +3213,16 @@
return assignNew('V', mce, Ity_V128, binop(op, vatom1, vatom2));
case Iop_GetElem8x16:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_I8, binop(op, vatom1, atom2));
case Iop_GetElem16x8:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_I16, binop(op, vatom1, atom2));
case Iop_GetElem32x4:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_I32, binop(op, vatom1, atom2));
case Iop_GetElem64x2:
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_I64, binop(op, vatom1, atom2));
/* Perm8x16: rearrange values in left arg using steering values
@@ -3240,7 +3281,7 @@
/* Same scheme as with all other shifts. Note: 10 Nov 05:
this is wrong now, scalar shifts are done properly lazily.
Vector shifts should be fixed too. */
- complainIfUndefined(mce, atom2, NULL);
+ complainIfUndefined(mce, atom2);
return assignNew('V', mce, Ity_V128, binop(op, vatom1, atom2));
/* I128-bit data-steering */
@@ -3940,7 +3981,7 @@
/* First, emit a definedness test for the address. This also sets
the address (shadow) to 'defined' following the test. */
- complainIfUndefined( mce, addr, NULL );
+ complainIfUndefined( mce, addr );
/* Now cook up a call to the relevant helper function, to read the
data V bits from shadow memory. */
@@ -4366,7 +4407,7 @@
/* First, emit a definedness test for the address. This also sets
the address (shadow) to 'defined' following the test. */
- complainIfUndefined( mce, addr, NULL );
+ complainIfUndefined( mce, addr );
/* Now decide which helper function to call to write the data V
bits into shadow memory. */
@@ -4593,7 +4634,7 @@
# endif
/* First check the guard. */
- complainIfUndefined(mce, d->guard, NULL);
+ complainIfUndefined(mce, d->guard);
/* Now round up all inputs and PCast over them. */
curr = definedOfType(Ity_I32);
@@ -4667,7 +4708,7 @@
should remove all but this test. */
IRType tyAddr;
tl_assert(d->mAddr);
- complainIfUndefined(mce, d->mAddr, NULL);
+ complainIfUndefined(mce, d->mAddr);
tyAddr = typeOfIRExpr(mce->sb->tyenv, d->mAddr);
tl_assert(tyAddr == Ity_I32 || tyAddr == Ity_I64);
@@ -5340,7 +5381,7 @@
static void do_shadow_StoreG ( MCEnv* mce, IRStoreG* sg )
{
if (0) VG_(printf)("XXXX StoreG\n");
- complainIfUndefined(mce, sg->guard, NULL);
+ complainIfUndefined(mce, sg->guard);
/* do_shadow_Store will check the definedness of sg->addr. */
do_shadow_Store( mce, sg->end,
sg->addr, 0/* addr bias */,
@@ -5352,7 +5393,7 @@
static void do_shadow_LoadG ( MCEnv* mce, IRLoadG* lg )
{
if (0) VG_(printf)("XXXX LoadG\n");
- complainIfUndefined(mce, lg->guard, NULL);
+ complainIfUndefined(mce, lg->guard);
/* expr2vbits_Load_guarded_General will check the definedness of
lg->addr. */
@@ -5745,7 +5786,7 @@
break;
case Ist_Exit:
- complainIfUndefined( &mce, st->Ist.Exit.guard, NULL );
+ complainIfUndefined( &mce, st->Ist.Exit.guard );
break;
case Ist_IMark:
@@ -5816,7 +5857,7 @@
VG_(printf)("\n\n");
}
- complainIfUndefined( &mce, sb_in->next, NULL );
+ complainIfUndefined( &mce, sb_in->next );
if (0 && verboze) {
for (j = first_stmt; j < sb_out->stmts_used; j++) {
|
|
From: Julian S. <js...@ac...> - 2012-12-14 12:50:39
|
> On Fri, 2012-12-14 at 21:32 +0900, Dave Goodell wrote: > > Thanks for testing this, Rich. > > > > Julian (or someone), would you please apply this patch at your > > convenience? Or would a bugzilla be preferred at this stage? > > I already bothered him on irc. It is in now r13180. Oh, I should have mentioned here that I committed it. Sorry. J |
|
From: Mark W. <mj...@re...> - 2012-12-14 12:42:36
|
On Fri, 2012-12-14 at 21:32 +0900, Dave Goodell wrote: > Thanks for testing this, Rich. > > Julian (or someone), would you please apply this patch at your > convenience? Or would a bugzilla be preferred at this stage? I already bothered him on irc. It is in now r13180. Thanks, Mark |
|
From: Dave G. <go...@mc...> - 2012-12-14 12:32:41
|
Thanks for testing this, Rich.
Julian (or someone), would you please apply this patch at your convenience? Or would a bugzilla be preferred at this stage?
-Dave
On Dec 13, 2012, at 1:31 PM GMT+09:00, Rich Coe wrote:
> This patch worked.
>
> Rich
>
> On Wed, 12 Dec 2012 13:28:32 +0100
> Mark Wielaard <mj...@re...> wrote:
>> On Wed, 2012-12-12 at 20:31 +0900, Dave Goodell wrote:
>>> On Dec 12, 2012, at 6:56 PM GMT+09:00, Mark Wielaard wrote:
>>>> Makes sense. New patch attached. Obviously all variants work fine on my
>>>> setup. If someone could test on a problematic one that would be
>>>> appreciated.
>>>
>>> I don't have easy access to a 10.6 or earlier machine with which to check this, sorry.
>>
>> Hopefully someone else can, otherwise we should just move things under
>> memcheck/tests/linux and be done with it I guess.
>>
>>> I don't feel strongly on this issue, but it's a great way to get
>>> burned in the future when the autoconf maintainers start using this
>>> variable for some random reason. You have correct m4 quoting in your
>>> patch, which is better than most cargo-cult autoconf fragments, so I
>>> assumed that you might be interested in following other best practices
>>> in this regard.
>>
>> I certainly do see your point. But I don't feel my auto* foo is strong
>> enough to fix all these issues in configure.in with this patch. And I do
>> think it is better to have all test be as similar as possible to each
>> other for now. But yeah, one day there will be problems :{ If just
>> because valgrind still has a configure.in, which will soon be dropped
>> because it has been deprecated for so long in favor of configure.ac:
>> https://lists.gnu.org/archive/html/autotools-announce/2012-11/msg00000.html
>> So if there is someone with strong auto* foo I am sure some cleanups
>> here will be appreciated.
>>
>>>>> You may also wish to include a note that this HAVE_STPNCPY is
>>>>> only valid in conjunction with "#define _GNU_SOURCE".
>>>>
>>>> But that turned out not to be true. The original didn't have it, and
>>>> apparently different "non-GNU" systems do have strpncpy.
>>>
>>> But your configure test explicitly defines "_GNU_SOURCE" in the test.
>>> So clients of HAVE_STPNCPY can only rely on its accuracy if they also
>>> define _GNU_SOURCE. I am not referring to any particular system
>>> having or not having the routine, nor directly the influence of
>>> _GNU_SOURCE on any particular system. Only that the test only checks
>>> for strncpy's existence in the presence of _GNU_SOURCE.
>>>
>>> This usually does not matter now, but 4 years down the road when
>>> someone else wants to gate on this #define and does not realize the
>>> subtle _GNU_SOURCE requirement. HAVE_X always seems like such a
>>> simple truth that it's easy to trust too much unless caveats are
>>> present in the name or the comments :)
>>
>> So, new version of the patch. This time with comment and tweaked HAVE_
>> to make thing totally clear attached.
>>
>> Cheers,
>>
>> Mark
>
>
> --
> Rich Coe rc...@wi...
|
|
From: Roland M. <rol...@nr...> - 2012-12-14 12:15:48
|
On Fri, Dec 14, 2012 at 11:38 AM, Julian Seward <js...@ac...> wrote: > On Friday, December 14, 2012, 邓尧 wrote: >> My apologies. I did some more tests, it's more than 2G, but still couldn't >> map more than 16G. I'm using valgrind-3.7.0 on linux-3.2.0 x86_64 > > Yes, that is as expected. By default V will only use 32GB of memory, > and that is divided more or less evenly between the application and > Valgrind itself. Hence your app will not be able to use more than > 16GB. > > The patch below doubles those limits, so you can go up to 32GB. > Give it a try. I would like to commit it, but it needs testing. [snip] WIthout looking at the sources myself... ... would it be hard to make this kind of change a command-line option ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |
|
From: Julian S. <js...@ac...> - 2012-12-14 10:38:17
|
On Friday, December 14, 2012, 邓尧 wrote:
> My apologies. I did some more tests, it's more than 2G, but still couldn't
> map more than 16G. I'm using valgrind-3.7.0 on linux-3.2.0 x86_64
Yes, that is as expected. By default V will only use 32GB of memory,
and that is divided more or less evenly between the application and
Valgrind itself. Hence your app will not be able to use more than
16GB.
The patch below doubles those limits, so you can go up to 32GB.
Give it a try. I would like to commit it, but it needs testing.
Oh, and upgrade to 3.8.1.
J
Index: memcheck/mc_main.c
===================================================================
--- memcheck/mc_main.c (revision 13179)
+++ memcheck/mc_main.c (working copy)
@@ -167,10 +167,10 @@
#else
-/* Just handle the first 32G fast and the rest via auxiliary
+/* Just handle the first 64G fast and the rest via auxiliary
primaries. If you change this, Memcheck will assert at startup.
See the definition of UNALIGNED_OR_HIGH for extensive comments. */
-# define N_PRIMARY_BITS 19
+# define N_PRIMARY_BITS 20
#endif
@@ -6524,11 +6524,11 @@
tl_assert(sizeof(Addr) == 8);
tl_assert(sizeof(UWord) == 8);
tl_assert(sizeof(Word) == 8);
- tl_assert(MAX_PRIMARY_ADDRESS == 0x7FFFFFFFFULL);
- tl_assert(MASK(1) == 0xFFFFFFF800000000ULL);
- tl_assert(MASK(2) == 0xFFFFFFF800000001ULL);
- tl_assert(MASK(4) == 0xFFFFFFF800000003ULL);
- tl_assert(MASK(8) == 0xFFFFFFF800000007ULL);
+ tl_assert(MAX_PRIMARY_ADDRESS == 0xFFFFFFFFFULL);
+ tl_assert(MASK(1) == 0xFFFFFFF000000000ULL);
+ tl_assert(MASK(2) == 0xFFFFFFF000000001ULL);
+ tl_assert(MASK(4) == 0xFFFFFFF000000003ULL);
+ tl_assert(MASK(8) == 0xFFFFFFF000000007ULL);
# endif
}
Index: coregrind/m_aspacemgr/aspacemgr-linux.c
===================================================================
--- coregrind/m_aspacemgr/aspacemgr-linux.c (revision 13179)
+++ coregrind/m_aspacemgr/aspacemgr-linux.c (working copy)
@@ -1649,7 +1649,7 @@
aspacem_minAddr = (Addr) 0x04000000; // 64M
# if VG_WORDSIZE == 8
- aspacem_maxAddr = (Addr)0x800000000 - 1; // 32G
+ aspacem_maxAddr = (Addr)0x1000000000ULL - 1; // 64G
# ifdef ENABLE_INNER
{ Addr cse = VG_PGROUNDDN( sp_at_startup ) - 1;
if (aspacem_maxAddr > cse)
|
|
From: <sv...@va...> - 2012-12-14 10:31:06
|
sewardj 2012-12-14 10:30:57 +0000 (Fri, 14 Dec 2012)
New Revision: 13180
Log:
Make memcheck/tests/stpncpy be dependent on the presence/absence of
stpncpy in libc, as determined by a configure test. n-i-bz.
(Mark Wielaard, mj...@re...)
Modified files:
trunk/configure.in
trunk/memcheck/tests/Makefile.am
trunk/memcheck/tests/stpncpy.c
trunk/memcheck/tests/stpncpy.vgtest
Modified: trunk/configure.in (+23 -0)
===================================================================
--- trunk/configure.in 2012-12-13 18:31:49 +00:00 (rev 13179)
+++ trunk/configure.in 2012-12-14 10:30:57 +00:00 (rev 13180)
@@ -1016,7 +1016,30 @@
AM_CONDITIONAL([HAVE_AT_FDCWD], [test x$ac_have_at_fdcwd = xyes])
+# Check for stpncpy function definition in string.h
+# This explicitly checks with _GNU_SOURCE defined since that is also
+# used in the test case (some systems might define it without anyway
+# since stpncpy is part of The Open Group Base Specifications Issue 7
+# IEEE Std 1003.1-2008.
+AC_MSG_CHECKING([for stpncpy])
+AC_LINK_IFELSE([AC_LANG_PROGRAM([[
+#define _GNU_SOURCE
+#include <string.h>
+]], [[
+ char *d;
+ char *s;
+ size_t n = 0;
+ char *r = stpncpy(d, s, n);
+]])], [
+ac_have_gnu_stpncpy=yes
+AC_MSG_RESULT([yes])
+], [
+ac_have_gnu_stpncpy=no
+AC_MSG_RESULT([no])
+])
+AM_CONDITIONAL([HAVE_GNU_STPNCPY], [test x$ac_have_gnu_stpncpy = xyes])
+
# Check for CLOCK_MONOTONIC
AC_MSG_CHECKING([for CLOCK_MONOTONIC])
Modified: trunk/memcheck/tests/stpncpy.c (+2 -0)
===================================================================
--- trunk/memcheck/tests/stpncpy.c 2012-12-13 18:31:49 +00:00 (rev 13179)
+++ trunk/memcheck/tests/stpncpy.c 2012-12-14 10:30:57 +00:00 (rev 13180)
@@ -1,5 +1,7 @@
#include <stdio.h>
#include <stdlib.h>
+
+#define _GNU_SOURCE
#include <string.h>
int main(int argc, char **argv)
Modified: trunk/memcheck/tests/stpncpy.vgtest (+1 -0)
===================================================================
--- trunk/memcheck/tests/stpncpy.vgtest 2012-12-13 18:31:49 +00:00 (rev 13179)
+++ trunk/memcheck/tests/stpncpy.vgtest 2012-12-14 10:30:57 +00:00 (rev 13180)
@@ -1,2 +1,3 @@
prog: stpncpy
+prereq: test -e ./stpncpy
vgopts: -q
Modified: trunk/memcheck/tests/Makefile.am (+4 -1)
===================================================================
--- trunk/memcheck/tests/Makefile.am 2012-12-13 18:31:49 +00:00 (rev 13179)
+++ trunk/memcheck/tests/Makefile.am 2012-12-14 10:30:57 +00:00 (rev 13180)
@@ -288,7 +288,6 @@
sbfragment \
sh-mem sh-mem-random \
sigaltstack signal2 sigprocmask static_malloc sigkill \
- stpncpy \
strchr \
str_tester \
supp_unknown supp1 supp2 suppfree \
@@ -307,6 +306,10 @@
check_PROGRAMS += dw4
endif
+if HAVE_GNU_STPNCPY
+check_PROGRAMS += stpncpy
+endif
+
AM_CFLAGS += $(AM_FLAG_M3264_PRI)
AM_CXXFLAGS += $(AM_FLAG_M3264_PRI)
|
|
From: 邓尧 <to...@gm...> - 2012-12-14 07:30:00
|
My apologies. I did some more tests, it's more than 2G, but still couldn't
map more than 16G. I'm using valgrind-3.7.0 on linux-3.2.0 x86_64
On Fri, Dec 14, 2012 at 11:54 AM, John Reiser <jr...@bi...> wrote:
> > Under 64-bit linux, a program could mmap() a very large space (at least
> 1T) when PROT_NONE is used. But when the program is running under valgrind,
> it could mmap() at most 2G, otherwise mmap() would return EINVAL.
> > Is this a limitation, bug or feature of valgrind ?
>
> It works for me in valgrind-3.8.1.
> -----
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/types.h>
> #include <sys/mman.h>
>
> main(int argc, char *argv[])
> {
> unsigned long len = 0;
> sscanf(argv[1], "%li", &len);
> void *addr = mmap(0, len, PROT_NONE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
> if (MAP_FAILED==addr) {
> printf("%ld{0x%lx) bytes failed.\n", len, len);
> return 1;
> }
> else {
> printf("%ld(0x%lx) bytes at %p\n", len, len, addr);
> return 0;
> }
> }
> -----
> $ gcc -g -o mmap-big mmap-big.c
> $ ./mmap-big 0x100000000 ## 4G
> 4294967296(0x100000000) bytes at 0x7f82fc92d000
> $ valgrind ./mmap-big 0x100000000
> ==18060== Memcheck, a memory error detector
> ==18060== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==18060== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==18060== Command: ./mmap-big 0x100000000
> ==18060==
> ==18060== Warning: set address range perms: large range [0x3aee0000,
> 0x13aee0000) (noaccess)
> 4294967296(0x100000000) bytes at 0x3aee0000
> ==18060==
> ==18060== HEAP SUMMARY:
> ==18060== in use at exit: 0 bytes in 0 blocks
> ==18060== total heap usage: 1 allocs, 1 frees, 256 bytes allocated
> ==18060==
> ==18060== All heap blocks were freed -- no leaks are possible
> ==18060==
> ==18060== For counts of detected and suppressed errors, rerun with: -v
> ==18060== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
> $
>
> --
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: Rich C. <rc...@wi...> - 2012-12-14 05:49:13
|
valgrind revision: 13179
VEX revision: 2590
C compiler: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Assembler:
C library: unknown
uname -mrs: Darwin 10.8.0 i386
Vendor version: unknown
Nightly build on macx86 ( Darwin 10.8.0 i386 )
Started at 2012-12-13 23:35:00 CST
Ended at 2012-12-13 23:49:04 CST
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../coregrind -I../../include -I../../VEX/pub -DVGA_x86=1 -DVGO_darwin=1 -DVGP_x86_darwin=1 -DVGPV_x86_darwin_vanilla=1 -Winline -Wall -Wshadow -g -arch i386 -Wno-long-long -Wwrite-strings -fno-stack-protector -Wno-write-strings -MT stpncpy.o -MD -MP -MF .deps/stpncpy.Tpo -c -o stpncpy.o stpncpy.c
stpncpy.c: In function 'main':
stpncpy.c:18: warning: implicit declaration of function 'stpncpy'
stpncpy.c:18: warning: incompatible implicit declaration of built-in function 'stpncpy'
stpncpy.c:21: warning: format '%zd' expects type 'signed size_t', but argument 3 has type 'int'
stpncpy.c:31: warning: format '%zd' expects type 'signed size_t', but argument 3 has type 'int'
mv -f .deps/stpncpy.Tpo .deps/stpncpy.Po
gcc -Winline -Wall -Wshadow -g -arch i386 -Wno-long-long -Wwrite-strings -fno-stack-protector -Wno-write-strings -o stpncpy stpncpy.o
Undefined symbols:
"_stpncpy", referenced from:
_main in stpncpy.o
_main in stpncpy.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[5]: *** [stpncpy] Error 1
make[4]: *** [check-am] Error 2
make[3]: *** [check-recursive] Error 1
make[2]: *** [check-recursive] Error 1
make[1]: *** [check-recursive] Error 1
make: *** [check] Error 2
Congratulations, all tests passed!
|
|
From: Philippe W. <phi...@sk...> - 2012-12-14 04:47:35
|
valgrind revision: 13179 VEX revision: 2590 C compiler: gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) Assembler: GNU assembler version 2.21.53.0.1-6.fc16 20110716 C library: GNU C Library development release version 2.14.90 uname -mrs: Linux 3.3.1-3.fc16.ppc64 ppc64 Vendor version: Fedora release 16 (Verne) Nightly build on gcc110 ( Fedora release 16 (Verne), ppc64 ) Started at 2012-12-13 20:00:12 PST Ended at 2012-12-13 20:45:50 PST 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 == 542 tests, 7 stderr failures, 3 stdout failures, 1 stderrB failure, 1 stdoutB failure, 2 post failures == gdbserver_tests/mcmain_pic (stdout) gdbserver_tests/mcmain_pic (stderr) gdbserver_tests/mcmain_pic (stdoutB) gdbserver_tests/mcmain_pic (stderrB) memcheck/tests/linux/getregset (stdout) memcheck/tests/linux/getregset (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) massif/tests/big-alloc (post) massif/tests/deep-D (post) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) |
|
From: Tom H. <to...@co...> - 2012-12-14 04:10:24
|
valgrind revision: 13179 VEX revision: 2590 C compiler: gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) Assembler: GNU assembler version 2.18.50.0.6-2 20080403 C library: GNU C Library stable release version 2.8 uname -mrs: Linux 3.5.3-1.fc17.x86_64 x86_64 Vendor version: Fedora release 9 (Sulphur) Nightly build on bristol ( x86_64, Fedora 9 ) Started at 2012-12-14 03:41:44 GMT Ended at 2012-12-14 04:10:10 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 == 617 tests, 1 stderr failure, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/amd64/insn-pcmpistri (stderr) none/tests/amd64/sse4-64 (stdout) |
|
From: Tom H. <to...@co...> - 2012-12-14 03:58:43
|
valgrind revision: 13179 VEX revision: 2590 C compiler: gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2) Assembler: GNU assembler version 2.19.51.0.14-3.fc11 20090722 C library: GNU C Library stable release version 2.10.2 uname -mrs: Linux 3.5.3-1.fc17.x86_64 x86_64 Vendor version: Fedora release 11 (Leonidas) Nightly build on bristol ( x86_64, Fedora 11 ) Started at 2012-12-14 03:31:07 GMT Ended at 2012-12-14 03:58:29 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 == 621 tests, 1 stderr failure, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/long_namespace_xml (stderr) none/tests/amd64/sse4-64 (stdout) |
|
From: Tom H. <to...@co...> - 2012-12-14 03:54:44
|
valgrind revision: 13179 VEX revision: 2590 C compiler: gcc (GCC) 4.4.5 20101112 (Red Hat 4.4.5-2) Assembler: GNU assembler version 2.20.51.0.2-20.fc13 20091009 C library: GNU C Library stable release version 2.12.2 uname -mrs: Linux 3.5.3-1.fc17.x86_64 x86_64 Vendor version: Fedora release 13 (Goddard) Nightly build on bristol ( x86_64, Fedora 13 ) Started at 2012-12-14 03:23:25 GMT Ended at 2012-12-14 03:54:31 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 == 621 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/pth_barrier3 (stderr) |
|
From: John R. <jr...@bi...> - 2012-12-14 03:53:26
|
> Under 64-bit linux, a program could mmap() a very large space (at least 1T) when PROT_NONE is used. But when the program is running under valgrind, it could mmap() at most 2G, otherwise mmap() would return EINVAL.
> Is this a limitation, bug or feature of valgrind ?
It works for me in valgrind-3.8.1.
-----
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/mman.h>
main(int argc, char *argv[])
{
unsigned long len = 0;
sscanf(argv[1], "%li", &len);
void *addr = mmap(0, len, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
if (MAP_FAILED==addr) {
printf("%ld{0x%lx) bytes failed.\n", len, len);
return 1;
}
else {
printf("%ld(0x%lx) bytes at %p\n", len, len, addr);
return 0;
}
}
-----
$ gcc -g -o mmap-big mmap-big.c
$ ./mmap-big 0x100000000 ## 4G
4294967296(0x100000000) bytes at 0x7f82fc92d000
$ valgrind ./mmap-big 0x100000000
==18060== Memcheck, a memory error detector
==18060== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==18060== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==18060== Command: ./mmap-big 0x100000000
==18060==
==18060== Warning: set address range perms: large range [0x3aee0000, 0x13aee0000) (noaccess)
4294967296(0x100000000) bytes at 0x3aee0000
==18060==
==18060== HEAP SUMMARY:
==18060== in use at exit: 0 bytes in 0 blocks
==18060== total heap usage: 1 allocs, 1 frees, 256 bytes allocated
==18060==
==18060== All heap blocks were freed -- no leaks are possible
==18060==
==18060== For counts of detected and suppressed errors, rerun with: -v
==18060== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
$
--
|
|
From: 邓尧 <to...@gm...> - 2012-12-14 03:36:16
|
Hi, Under 64-bit linux, a program could mmap() a very large space (at least 1T) when PROT_NONE is used. But when the program is running under valgrind, it could mmap() at most 2G, otherwise mmap() would return EINVAL. Is this a limitation, bug or feature of valgrind ? Thanks Yao |
|
From: Christian B. <bor...@de...> - 2012-12-14 03:13:38
|
valgrind revision: 13179 VEX revision: 2590 C compiler: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] Assembler: GNU assembler (GNU Binutils; SUSE Linux Enterprise 11) 2.21.1 C library: GNU C Library stable release version 2.11.3 (20110527) uname -mrs: Linux 3.0.42-0.7-default s390x Vendor version: Welcome to SUSE Linux Enterprise Server 11 SP2 (s390x) - Kernel %r (%t). Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) ) Started at 2012-12-14 03:45:01 CET Ended at 2012-12-14 04:13:27 CET Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 615 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == |
|
From: Christian B. <bor...@de...> - 2012-12-14 03:08:13
|
valgrind revision: 13179 VEX revision: 2590 C compiler: gcc (GCC) 4.6.1 20110908 (Red Hat 4.6.1-9bb4) Assembler: GNU assembler version 2.21.51.0.6-6bb6.fc15 20110118 C library: GNU C Library stable release version 2.14.1 uname -mrs: Linux 3.6.8-57.x.20121204-s390xperformance s390x Vendor version: unknown Nightly build on fedora390 ( Fedora 15 with devel libc/toolchain on z196 (s390x) ) Started at 2012-12-14 03:45:01 CET Ended at 2012-12-14 04:08:17 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 == 616 tests, 2 stderr failures, 0 stdout failures, 6 stderrB failures, 0 stdoutB failures, 0 post failures == gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) |