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
(12) |
2
(5) |
3
(12) |
4
(9) |
5
(4) |
6
(7) |
|
7
(6) |
8
(10) |
9
(5) |
10
(5) |
11
(4) |
12
(7) |
13
(19) |
|
14
(11) |
15
(9) |
16
(6) |
17
(21) |
18
(13) |
19
(12) |
20
(9) |
|
21
(22) |
22
(24) |
23
(21) |
24
(12) |
25
(6) |
26
(3) |
27
(4) |
|
28
(3) |
29
(5) |
30
(11) |
31
(7) |
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2008-12-13 23:00:51
|
On Sat, 13 Dec 2008, zhangyan wrote:
> #define N 79814486
> void foo()
> {
> char *a=(char*)malloc(N);
> }
> int main()
> {
> foo();
> return 0;
> }
>
> The memory allocated by (char*)malloc(N) is definitely lost,but why the
> valgrind give me the "possibly lost".And do you think is there any possible
> value points into the middle of the allocated block ??? if it's,what is the
> value which points to the allocated block possibly???
You need to understand what Valgrind means by "possibly" lost. Read the
manual:
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks
There could be random values in the address space that look like pointers
into a block, but which aren't really. The bigger a block is, the more
likely this is to happen.
Nick
|
|
From: <sv...@va...> - 2008-12-13 22:27:12
|
Author: njn
Date: 2008-12-13 22:27:05 +0000 (Sat, 13 Dec 2008)
New Revision: 8824
Log:
Update an FAQ to account for --track-origins=yes.
Modified:
trunk/docs/xml/FAQ.xml
Modified: trunk/docs/xml/FAQ.xml
===================================================================
--- trunk/docs/xml/FAQ.xml 2008-12-13 18:46:44 UTC (rev 8823)
+++ trunk/docs/xml/FAQ.xml 2008-12-13 22:27:05 UTC (rev 8824)
@@ -542,10 +542,14 @@
memory values?</para>
</question>
<answer id="a-undeferrors">
- <para>We'd love to improve these errors, but we don't know how to do it
- without huge performance penalties.</para>
+ <para>Prior to version 3.4.0, the answer was "we don't know how to do it
+ without huge performance penalties". As of 3.4.0, try using the
+ <option>--track-origins=yes</option> flag. It will run slower than
+ usual, but will give you extra information about the origin of
+ uninitialised values.</para>
- <para>You can use the client request
+ <para>Or if you want to do it the old fashioned way, you can use the
+ client request
<computeroutput>VALGRIND_CHECK_VALUE_IS_DEFINED</computeroutput> to help
track these errors down -- work backwards from the point where the
uninitialised error occurs, checking suspect values until you find the
|
|
From: <sv...@va...> - 2008-12-13 18:46:49
|
Author: sewardj Date: 2008-12-13 18:46:44 +0000 (Sat, 13 Dec 2008) New Revision: 8823 Log: Include vg-in-place in the distro tarball. Modified: trunk/Makefile.am Modified: trunk/Makefile.am =================================================================== --- trunk/Makefile.am 2008-12-13 16:53:35 UTC (rev 8822) +++ trunk/Makefile.am 2008-12-13 18:46:44 UTC (rev 8823) @@ -88,7 +88,8 @@ valgrind.spec.in valgrind.pc.in \ Makefile.all.am Makefile.tool.am Makefile.core.am \ Makefile.tool-inplace.am \ - $(vex_primary_sources) + $(vex_primary_sources) \ + vg-in-place install-exec-hook: $(mkinstalldirs) $(DESTDIR)$(valdir) |
|
From: <sv...@va...> - 2008-12-13 16:53:44
|
Author: sewardj
Date: 2008-12-13 16:53:35 +0000 (Sat, 13 Dec 2008)
New Revision: 8822
Log:
Update.
Modified:
trunk/docs/internals/3_3_BUGSTATUS.txt
Modified: trunk/docs/internals/3_3_BUGSTATUS.txt
===================================================================
--- trunk/docs/internals/3_3_BUGSTATUS.txt 2008-12-13 16:45:19 UTC (rev 8821)
+++ trunk/docs/internals/3_3_BUGSTATUS.txt 2008-12-13 16:53:35 UTC (rev 8822)
@@ -200,14 +200,38 @@
172563 Fixd vx???? amd64->IR: 0xD9 0xF5 - fprem1
-173099 LOW pend .lds linker script generation error
- w/ plausible patch
+173099 Fixd 8758 .lds linker script generation error
173177 Fixd 8720 [x86_64] WARNING: unhandled syscall: 125/126/179
(capget/capset/quotactl)
+173751 Fixd vx1876 amd64->IR: 0x48 0xF 0x6F 0x45
+ (even more redundant prefixes)
+174532 WF DUP amd64->IR: 0x48 0xF 0xED 0x0
+ == 173751
+174908 Fixd 8774 --log-file value not expanded correctly for core file
+175044 Fixd 8769 Add lookup_dcookie for amd64
+
+175138 WF pend aspacem assertion failed: segment_is_sane at
+ m_aspacemgr/aspacemgr-linux.c:1412 (add_segment)
+
+175150 Fixd vx1873 x86->IR: 0xF2 0xF 0x11 0xC1 (movss xmm1, xmm0)
+ non-binutils encoding
+
+[patch] fix RPM/spec build... (Daniel J Blueman, @dev, 12 Aug 08)
+
+FAQ.html and FAQ.html (Greg Czajknowski, @users, 21 Nov 08)
+
+n-i-bz Fixd 8812 MPI_Init(0,0) is valid but libmpiwrap.c segfaults
+
+building in an env without gdb gives bogus gdb attach (i'm sure i
+fixed this, but where is it?)
+
+Better return values from VG_(record_error) (kcc)
+
+
---------- Bugs fixed in 3.3.1 -------------------------------------
/////////////////////////////////////////////////////////////////
|
|
From: <sv...@va...> - 2008-12-13 16:49:53
|
Author: sewardj
Date: 2008-12-13 16:49:46 +0000 (Sat, 13 Dec 2008)
New Revision: 1876
Log:
Handle some redundant REX.W prefixes on code from IPP (Intel
Performance Primitives). This fixes #173751, at least for the test
cases so far provided.
Modified:
trunk/priv/guest-amd64/toIR.c
Modified: trunk/priv/guest-amd64/toIR.c
===================================================================
--- trunk/priv/guest-amd64/toIR.c 2008-12-04 00:05:12 UTC (rev 1875)
+++ trunk/priv/guest-amd64/toIR.c 2008-12-13 16:49:46 UTC (rev 1876)
@@ -6457,7 +6457,8 @@
case 0x6F:
/* MOVQ (src)mmxreg-or-mem, (dst)mmxreg */
- if (sz != 4)
+ if (sz != 4
+ && /*ignore redundant REX.W*/!(sz==8 && haveNo66noF2noF3(pfx)))
goto mmx_decode_failure;
modrm = getUChar(delta);
if (epartIsReg(modrm)) {
@@ -6477,7 +6478,8 @@
case 0x7F:
/* MOVQ (src)mmxreg, (dst)mmxreg-or-mem */
- if (sz != 4)
+ if (sz != 4
+ && /*ignore redundant REX.W*/!(sz==8 && haveNo66noF2noF3(pfx)))
goto mmx_decode_failure;
modrm = getUChar(delta);
if (epartIsReg(modrm)) {
@@ -6503,7 +6505,8 @@
case 0xEC:
case 0xED: /* PADDSgg (src)mmxreg-or-mem, (dst)mmxreg */
- if (sz != 4)
+ if (sz != 4
+ && /*ignore redundant REX.W*/!(sz==8 && haveNo66noF2noF3(pfx)))
goto mmx_decode_failure;
delta = dis_MMXop_regmem_to_reg ( vbi, pfx, delta, opc, "padds", True );
break;
@@ -6599,7 +6602,8 @@
case 0x60:
case 0x61:
case 0x62: /* PUNPCKLgg (src)mmxreg-or-mem, (dst)mmxreg */
- if (sz != 4)
+ if (sz != 4
+ && /*ignore redundant REX.W*/!(sz==8 && haveNo66noF2noF3(pfx)))
goto mmx_decode_failure;
delta = dis_MMXop_regmem_to_reg ( vbi, pfx, delta, opc, "punpckl", True );
break;
@@ -9566,7 +9570,7 @@
/* F3 0F 10 = MOVSS -- move 32 bits from E (mem or lo 1/4 xmm) to G
(lo 1/4 xmm). If E is mem, upper 3/4 of G is zeroed out. */
if (haveF3no66noF2(pfx)
- && (sz == 4|| /* ignore redundant REX.W */ sz == 8)
+ && (sz == 4 || /* ignore redundant REX.W */ sz == 8)
&& insn[0] == 0x0F && insn[1] == 0x10) {
modrm = getUChar(delta+2);
if (epartIsReg(modrm)) {
@@ -11541,7 +11545,8 @@
/* 66 0F C5 = PEXTRW -- extract 16-bit field from xmm(E) and put
zero-extend of it in ireg(G). */
- if (have66noF2noF3(pfx) && sz == 2
+ if (have66noF2noF3(pfx)
+ && (sz == 2 || /* ignore redundant REX.W */ sz == 8)
&& insn[0] == 0x0F && insn[1] == 0xC5) {
modrm = insn[2];
if (epartIsReg(modrm)) {
@@ -11574,7 +11579,8 @@
/* 66 0F C4 = PINSRW -- get 16 bits from E(mem or low half ireg) and
put it into the specified lane of xmm(G). */
- if (have66noF2noF3(pfx) && sz == 2
+ if (have66noF2noF3(pfx)
+ && (sz == 2 || /* ignore redundant REX.W */ sz == 8)
&& insn[0] == 0x0F && insn[1] == 0xC4) {
Int lane;
t4 = newTemp(Ity_I16);
@@ -11687,7 +11693,8 @@
ireg(G). Doing this directly is just too cumbersome; give up
therefore and call a helper. */
/* UInt x86g_calculate_sse_pmovmskb ( ULong w64hi, ULong w64lo ); */
- if (have66noF2noF3(pfx) && sz == 2
+ if (have66noF2noF3(pfx)
+ && (sz == 2 || /* ignore redundant REX.W */ sz == 8)
&& insn[0] == 0x0F && insn[1] == 0xD7) {
modrm = insn[2];
if (epartIsReg(modrm)) {
|
|
From: <sv...@va...> - 2008-12-13 16:45:25
|
Author: sewardj
Date: 2008-12-13 16:45:19 +0000 (Sat, 13 Dec 2008)
New Revision: 8821
Log:
Make sure $mflag_primary is used in the tests for Boost and QtCore
features. Also add a big comment explaining why this is important.
Modified:
trunk/configure.in
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2008-12-13 01:20:21 UTC (rev 8820)
+++ trunk/configure.in 2008-12-13 16:45:19 UTC (rev 8821)
@@ -785,71 +785,6 @@
])
-# Check whether the boost library 1.35 or later has been installed.
-# The Boost.Threads library has undergone a major rewrite in version 1.35.0.
-
-AC_MSG_CHECKING([for boost])
-
-AC_LANG(C++)
-safe_CXXFLAGS=$CXXFLAGS
-CXXFLAGS="-lboost_thread-mt"
-
-AC_LINK_IFELSE(
-[
-#include <boost/thread.hpp>
-static void thread_func(void)
-{ }
-int main(int argc, char** argv)
-{
- boost::thread t(thread_func);
- return 0;
-}
-],
-[
-ac_have_boost_1_35=yes
-AC_SUBST([BOOST_CFLAGS], [])
-AC_SUBST([BOOST_LIBS], ["${CXXFLAGS}"])
-AC_MSG_RESULT([yes])
-], [
-ac_have_boost_1_35=no
-AC_MSG_RESULT([no])
-])
-
-CXXFLAGS=$safe_CXXFLAGS
-AC_LANG(C)
-
-AM_CONDITIONAL([HAVE_BOOST_1_35], [test x$ac_have_boost_1_35 = xyes])
-
-
-# does this compiler support -fopenmp, does it have the include file
-# <omp.h> and does it have libgomp ?
-
-AC_MSG_CHECKING([for OpenMP])
-
-safe_CFLAGS=$CFLAGS
-CFLAGS="-fopenmp"
-
-AC_LINK_IFELSE(
-[
-#include <omp.h>
-int main(int argc, char** argv)
-{
- omp_set_dynamic(0);
- return 0;
-}
-],
-[
-ac_have_openmp=yes
-AC_MSG_RESULT([yes])
-], [
-ac_have_openmp=no
-AC_MSG_RESULT([no])
-])
-CFLAGS=$safe_CFLAGS
-
-AM_CONDITIONAL([HAVE_OPENMP], [test x$ac_have_openmp = xyes])
-
-
# does this compiler support -maltivec and does it have the include file
# <altivec.h> ?
@@ -1489,6 +1424,22 @@
AM_CONDITIONAL(BUILD_MPIWRAP_SEC, test x$ac_have_mpi2_sec = xyes)
+# There now follow some tests for QtCore, Boost, and OpenMP. These
+# tests are present because Drd has some regression tests that use
+# these packages. All regression test programs all compiled only
+# for the primary target. And so it is important that the configure
+# checks that follow, use the correct -m32 or -m64 flag for the
+# primary target (called $mflag_primary). Otherwise, we can end up
+# in a situation (eg) where, on amd64-linux, the test for Boost checks
+# for usable 64-bit Boost facilities, but because we are doing a 32-bit
+# only build (meaning, the primary target is x86-linux), the build
+# of the regtest programs that use Boost fails, because they are
+# build as 32-bit (IN THIS EXAMPLE).
+#
+# Hence: ALWAYS USE $mflag_primary FOR CONFIGURE TESTS FOR FACILITIES
+# NEEDED BY THE REGRESSION TEST PROGRAMS.
+
+
# The test below verifies whether the QtCore package been installed.
# This test works as follows:
# - If pkg-config was not installed at the time autogen.sh was run,
@@ -1517,10 +1468,7 @@
# programs with QtCore succeeds.
AC_LANG(C++)
safe_CXXFLAGS="${CXXFLAGS}"
- CXXFLAGS="${QTCORE_CFLAGS} ${QTCORE_LIBS}"
- if test x$vg_cv_only32bit = xyes; then
- CXXFLAGS="${CXXFLAGS} -m32"
- fi
+ CXXFLAGS="${QTCORE_CFLAGS} ${QTCORE_LIBS} $mflag_primary"
AC_TRY_LINK(
[#include <QMutex>],
[QMutex Mutex;],
@@ -1551,7 +1499,7 @@
AC_MSG_CHECKING([for Qt4 QMutex::tryLock(int)])
AC_LANG(C++)
safe_CXXFLAGS="${CXXFLAGS}"
- CXXFLAGS="${QTCORE_CFLAGS}"
+ CXXFLAGS="${QTCORE_CFLAGS} $mflag_primary"
AC_TRY_COMPILE([
#include <QtCore/QMutex>
],
@@ -1573,6 +1521,71 @@
fi
+# Check whether the boost library 1.35 or later has been installed.
+# The Boost.Threads library has undergone a major rewrite in version 1.35.0.
+
+AC_MSG_CHECKING([for boost])
+
+AC_LANG(C++)
+safe_CXXFLAGS=$CXXFLAGS
+CXXFLAGS="-lboost_thread-mt $mflag_primary"
+
+AC_LINK_IFELSE(
+[
+#include <boost/thread.hpp>
+static void thread_func(void)
+{ }
+int main(int argc, char** argv)
+{
+ boost::thread t(thread_func);
+ return 0;
+}
+],
+[
+ac_have_boost_1_35=yes
+AC_SUBST([BOOST_CFLAGS], [])
+AC_SUBST([BOOST_LIBS], ["${CXXFLAGS}"])
+AC_MSG_RESULT([yes])
+], [
+ac_have_boost_1_35=no
+AC_MSG_RESULT([no])
+])
+
+CXXFLAGS=$safe_CXXFLAGS
+AC_LANG(C)
+
+AM_CONDITIONAL([HAVE_BOOST_1_35], [test x$ac_have_boost_1_35 = xyes])
+
+
+# does this compiler support -fopenmp, does it have the include file
+# <omp.h> and does it have libgomp ?
+
+AC_MSG_CHECKING([for OpenMP])
+
+safe_CFLAGS=$CFLAGS
+CFLAGS="-fopenmp"
+
+AC_LINK_IFELSE(
+[
+#include <omp.h>
+int main(int argc, char** argv)
+{
+ omp_set_dynamic(0);
+ return 0;
+}
+],
+[
+ac_have_openmp=yes
+AC_MSG_RESULT([yes])
+], [
+ac_have_openmp=no
+AC_MSG_RESULT([no])
+])
+CFLAGS=$safe_CFLAGS
+
+AM_CONDITIONAL([HAVE_OPENMP], [test x$ac_have_openmp = xyes])
+
+
# -------------------- ok. We're done. --------------------
AC_OUTPUT(
|
|
From: zhangyan <zha...@ba...> - 2008-12-13 12:23:17
|
> No, the two things are unrelated. Whether you get "definitely" or
"possibly" > lost is largely a matter of luck -- if there are any values
that could conceivably > point into the middle of a block, it's considered
"possibly" lost. (See the 〉> manual for more explanation.) As you make
blocks bigger, this becomes more > likely.
Well,3ks you for explanation of report the warning of "set address range
perms",it's impressed.But to the second question,as you watch this source
file
#define N 79814486
void foo()
{
char *a=(char*)malloc(N);
}
int main()
{
foo();
return 0;
}
The memory allocated by (char*)malloc(N) is definitely lost,but why the
valgrind give me the "possibly lost".And do you think is there any possible
value points into the middle of the allocated block ??? if it's,what is the
value which points to the allocated block possibly???
I really appreciate your explanation of the warning as a developer,because
our company come across many warnings of this kind,and we are really worried
about that whether these warnings indicating our programs have a bunch of
bugs:-)
|
|
From: Nicholas N. <nj...@cs...> - 2008-12-13 11:27:49
|
On Sat, 13 Dec 2008, zhangyan wrote:
> I have used the valgrind for a long time,and recently I am writing a program
> which will allocate a very large block of memory once a time,and The
> valgrind will always report the warning "set address range perms: large
> range <number>".
>
> That's is really annoying.
>
> The version of valgrind which I use is 3.3.0,and I have read the source code
> of memcheck/mc_main.c this file,
>
> that indicate if we allocate a memory more than 100MB once a time,the
> valgrind will report this warning. So I want to know there is any reason why
> 100MB exactly???
The number 100MB isn't particularly significant. The warning is there to
help debug Valrind itself -- at various times the memory size number has
been incorrect, and flagging large allocations catches many of these cases.
So feel free to comment out the relevant line and recompile.
> And I guess the reason why set a threshold is that if I allocate too much
> bytes as a block a time,the valgrind can't trace it exactly,even this block
> of memory will be "definitely lost",the valgrind will report "possibly
> lost".Is it correct???
>
> I made this guess becauase recently I have done a experiement to test
> valgrind's exactness,I allocate a specific number of bytes once a time,and
> the program is like this
>
> #define N 79814486
>
> void foo()
>
> {
>
> char *a=(char*)malloc(N);
>
> }
>
> int main()
>
> {
>
> foo();
>
> return 0;
>
> }
>
> And I thought the valgrind will report the error message of "definitely
> lost",but when the N is more than or equal to 79814486,the valgrind will
> report the error message of "possbily lost" instead of "definitely lost".
>
> So I guess the reason why the developer set the 100MB is because if we
> allocate too big
No, the two things are unrelated. Whether you get "definitely" or
"possibly" lost is largely a matter of luck -- if there are any values that
could conceivably point into the middle of a block, it's considered
"possibly" lost. (See the manual for more explanation.) As you make blocks
bigger, this becomes more likely.
Nick
|
|
From: zhangyan <zha...@ba...> - 2008-12-13 09:34:39
|
I have used the valgrind for a long time,and recently I am writing a program
which will allocate a very large block of memory once a time,and The
valgrind will always report the warning "set address range perms: large
range <number>".
That's is really annoying.
The version of valgrind which I use is 3.3.0,and I have read the source code
of memcheck/mc_main.c this file,
that indicate if we allocate a memory more than 100MB once a time,the
valgrind will report this warning. So I want to know there is any reason why
100MB exactly???
And I guess the reason why set a threshold is that if I allocate too much
bytes as a block a time,the valgrind can't trace it exactly,even this block
of memory will be "definitely lost",the valgrind will report "possibly
lost".Is it correct???
I made this guess becauase recently I have done a experiement to test
valgrind's exactness,I allocate a specific number of bytes once a time,and
the program is like this
#define N 79814486
void foo()
{
char *a=(char*)malloc(N);
}
int main()
{
foo();
return 0;
}
And I thought the valgrind will report the error message of "definitely
lost",but when the N is more than or equal to 79814486,the valgrind will
report the error message of "possbily lost" instead of "definitely lost".
So I guess the reason why the developer set the 100MB is because if we
allocate too big
|
|
From: Tom H. <th...@cy...> - 2008-12-13 05:50:41
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-12-13 03:05:04 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 471 tests, 24 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/bar_bad (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/pth_barrier1 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) |
|
From: Tom H. <th...@cy...> - 2008-12-13 04:11:54
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-12-13 03:15:03 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 == 374 tests, 89 stderr failures, 1 stdout failure, 29 post failures == exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) helgrind/tests/bar_bad (stderr) helgrind/tests/bar_trivial (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/pth_barrier1 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/rwlock_test (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc04_free_lock (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-names (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/mismatches (stderr) memcheck/tests/origin1-yes (stderr) memcheck/tests/origin4-many (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) |
|
From: Robert W. <rj...@du...> - 2008-12-13 04:03:49
|
Sadly, no. Valgrind shares the address space of the guest process, which would mean libc would get linked into the address space twice. There's no telling how libc would react to that. Regards, Robert. On Dec 12, 2008, at 6:33 PM, "Igor Shaul" <min...@gm...> wrote: > Hi, > I would like to write a valgrind tool that uses the standard c > library (actually, I must link my tool to another library, which > happens to use stdlib). I noticed that all the tools link with - > nodefaultlibs flag, and if said flag is removed, then naturally no > main() is found (stdlib requires a main). So, is there a natural way > to use stdlib in my valgrind tool? > > Thank you, > Igor > --- > --- > --- > --------------------------------------------------------------------- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, > Nevada. > The future of the web can't happen without you. Join us at MIX09 to > help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Tom H. <th...@cy...> - 2008-12-13 03:51:29
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2008-12-13 03:20:03 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 == 479 tests, 45 stderr failures, 0 stdout failures, 0 post failures == cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stderr) cachegrind/tests/wrap5 (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) callgrind/tests/simwork1 (stderr) callgrind/tests/simwork2 (stderr) callgrind/tests/simwork3 (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/preen_invars (stderr) helgrind/tests/bar_bad (stderr) helgrind/tests/bar_trivial (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/pth_barrier1 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/rwlock_test (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) |
|
From: Tom H. <th...@cy...> - 2008-12-13 03:47:58
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-12-13 03:25:06 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 475 tests, 23 stderr failures, 4 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/pth_barrier1 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2008-12-13 03:31:57
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2008-12-13 03:10:06 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 476 tests, 30 stderr failures, 1 stdout failure, 0 post failures == cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stderr) cachegrind/tests/wrap5 (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) callgrind/tests/simwork1 (stderr) callgrind/tests/simwork2 (stderr) callgrind/tests/simwork3 (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/pth_barrier1 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2008-12-13 03:30:05
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-12-13 03:00:04 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 477 tests, 37 stderr failures, 3 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) helgrind/tests/bar_bad (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/pth_barrier1 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/rwlock_test (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) |
|
From: Igor S. <min...@gm...> - 2008-12-13 02:34:04
|
Hi, I would like to write a valgrind tool that uses the standard c library (actually, I must link my tool to another library, which happens to use stdlib). I noticed that all the tools link with -nodefaultlibs flag, and if said flag is removed, then naturally no main() is found (stdlib requires a main). So, is there a natural way to use stdlib in my valgrind tool? Thank you, Igor |
|
From: <sv...@va...> - 2008-12-13 01:20:27
|
Author: sewardj
Date: 2008-12-13 01:20:21 +0000 (Sat, 13 Dec 2008)
New Revision: 8820
Log:
Avoid causing an assertion failure in VG_(make_ExeContext_from_StackTrace)
in the case where VG_(clo_backtrace_size) < N_FRAMES (that is, with
--num-callers=N where N < N_FRAMES).
Modified:
trunk/helgrind/libhb_core.c
Modified: trunk/helgrind/libhb_core.c
===================================================================
--- trunk/helgrind/libhb_core.c 2008-12-13 01:18:38 UTC (rev 8819)
+++ trunk/helgrind/libhb_core.c 2008-12-13 01:20:21 UTC (rev 8820)
@@ -2955,6 +2955,10 @@
return (void*)( ((UWord)p) & ((UWord)w) );
}
+inline static UInt min_UInt ( UInt a, UInt b ) {
+ return a < b ? a : b;
+}
+
/* Compare the intervals [a1,a1+n1) and [a2,a2+n2). Return -1 if the
first interval is lower, 1 if the first interval is higher, and 0
if there is any overlap. Redundant paranoia with casting is there
@@ -3177,7 +3181,8 @@
tl_assert(cand_rcec->magic == RCEC_MAGIC);
tl_assert(cand_szB >= 1);
*resEC = VG_(make_ExeContext_from_StackTrace)(
- &cand_rcec->frames[1], N_FRAMES
+ &cand_rcec->frames[1],
+ min_UInt(N_FRAMES, VG_(clo_backtrace_size))
);
*resThr = cand_thr;
*resSzB = cand_szB;
|
|
From: <sv...@va...> - 2008-12-13 01:18:46
|
Author: sewardj
Date: 2008-12-13 01:18:38 +0000 (Sat, 13 Dec 2008)
New Revision: 8819
Log:
Add a couple of suppressions relating to unwinding the stack following
pthread_exit.
Modified:
trunk/glibc-2.34567-NPTL-helgrind.supp
Modified: trunk/glibc-2.34567-NPTL-helgrind.supp
===================================================================
--- trunk/glibc-2.34567-NPTL-helgrind.supp 2008-12-12 13:23:03 UTC (rev 8818)
+++ trunk/glibc-2.34567-NPTL-helgrind.supp 2008-12-13 01:18:38 UTC (rev 8819)
@@ -543,3 +543,27 @@
...
fun:dlsym
}
+
+####################################################
+# Other stuff.
+#
+# pthread_exit apparently calls some kind of unwind
+# mechanism - maybe to remove some number of frames
+# from the thread's stack, so as to get back to the
+# outermost frame for the thread? Anyway..
+
+{
+ helgrind---*Unwind*-...-pthread_exit
+ Helgrind:Race
+ fun:*Unwind*
+ ...
+ fun:pthread_exit
+}
+
+{
+ helgrind---...-*Unwind*-*pthread_unwind*
+ Helgrind:Race
+ ...
+ fun:*Unwind*
+ fun:*pthread_unwind*
+}
|