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
(9) |
2
(7) |
3
(15) |
4
(14) |
|
5
(12) |
6
(18) |
7
(16) |
8
(13) |
9
(14) |
10
(20) |
11
(26) |
|
12
(14) |
13
(25) |
14
(20) |
15
(15) |
16
(14) |
17
(13) |
18
(12) |
|
19
(8) |
20
(16) |
21
(15) |
22
(37) |
23
(15) |
24
(18) |
25
(12) |
|
26
(8) |
27
(13) |
28
(12) |
|
|
|
|
|
From: <sv...@va...> - 2006-02-20 20:57:42
|
Author: njn
Date: 2006-02-20 20:57:33 +0000 (Mon, 20 Feb 2006)
New Revision: 5661
Log:
Add another possible output for pointer-trace.
Added:
branches/COMPVBITS/memcheck/tests/pointer-trace.stderr.exp3
Added: branches/COMPVBITS/memcheck/tests/pointer-trace.stderr.exp3
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/COMPVBITS/memcheck/tests/pointer-trace.stderr.exp3 =
(rev 0)
+++ branches/COMPVBITS/memcheck/tests/pointer-trace.stderr.exp3 2006-02-2=
0 20:57:33 UTC (rev 5661)
@@ -0,0 +1,30 @@
+
+searching for pointers to 1 not-freed blocks.
+checked ... bytes.
+
+LEAK SUMMARY:
+ definitely lost: 0 bytes in 0 blocks.
+ possibly lost: 0 bytes in 0 blocks.
+ still reachable: 1,048,576 bytes in 1 blocks.
+ suppressed: 0 bytes in 0 blocks.
+Reachable blocks (those to which a pointer was found) are not shown.
+To see them, rerun with: --show-reachable=3Dyes
+
+ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+malloc/free: in use at exit: 1,048,576 bytes in 1 blocks.
+malloc/free: 1 allocs, 0 frees, 1,048,576 bytes allocated.
+For counts of detected errors, rerun with: -v
+searching for pointers to 1 not-freed blocks.
+checked ... bytes.
+
+1,048,576 bytes in 1 blocks are possibly lost in loss record 1 of 1
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: main (pointer-trace.c:24)
+
+LEAK SUMMARY:
+ definitely lost: 0 bytes in 0 blocks.
+ possibly lost: 1,048,576 bytes in 1 blocks.
+ still reachable: 0 bytes in 0 blocks.
+ suppressed: 0 bytes in 0 blocks.
+Reachable blocks (those to which a pointer was found) are not shown.
+To see them, rerun with: --show-reachable=3Dyes
|
|
From: <sv...@va...> - 2006-02-20 20:33:40
|
Author: njn
Date: 2006-02-20 20:33:27 +0000 (Mon, 20 Feb 2006)
New Revision: 5660
Log:
Fix a long-standing bug in the compressed V bits handling. When
copy_address_range_state() copies a partially defined byte, it failed to
also copy the corresponding entry in the sec-V-bits table. This later ca=
use
sec-V-bit table lookup failures. Big thanks to Julian for diagnosing thi=
s.
I added a regtest for this, and some warnings in comments. I couldn't th=
ink
of a way to make it impossible in the code without killing performance,
unfortunately.
Added:
branches/COMPVBITS/memcheck/tests/pdb-realloc.c
branches/COMPVBITS/memcheck/tests/pdb-realloc.stderr.exp
branches/COMPVBITS/memcheck/tests/pdb-realloc.vgtest
Modified:
branches/COMPVBITS/memcheck/mc_main.c
branches/COMPVBITS/memcheck/tests/Makefile.am
Modified: branches/COMPVBITS/memcheck/mc_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/COMPVBITS/memcheck/mc_main.c 2006-02-19 14:05:28 UTC (rev 56=
59)
+++ branches/COMPVBITS/memcheck/mc_main.c 2006-02-20 20:33:27 UTC (rev 56=
60)
@@ -535,6 +535,10 @@
// clever things like combine the auxmap check (in
// get_secmap_{read,writ}able) with alignment checks.
=20
+// *** WARNING! ***
+// Any time this function is called, if it is possible that vabits2
+// is equal to VA_BITS2_OTHER, then the corresponding entry in the
+// sec-V-bits table must also be set!
static inline
void set_vabits2 ( Addr a, UChar vabits2 )
{
@@ -921,10 +925,14 @@
PROF_EVENT(150, "set_address_range_perms");
=20
/* Check the V+A bits make sense. */
- tl_assert(vabits16 =3D=3D VA_BITS16_NOACCESS ||
- vabits16 =3D=3D VA_BITS16_WRITABLE ||
- vabits16 =3D=3D VA_BITS16_READABLE);
+ tl_assert(VA_BITS16_NOACCESS =3D=3D vabits16 ||
+ VA_BITS16_WRITABLE =3D=3D vabits16 ||
+ VA_BITS16_READABLE =3D=3D vabits16);
=20
+ // This code should never write PDBs; ensure this. (See comment abo=
ve
+ // set_vabits2().)
+ tl_assert(VA_BITS2_OTHER !=3D vabits2);
+
if (lenT =3D=3D 0)
return;
=20
@@ -944,6 +952,9 @@
{
// Endianness doesn't matter here because all bytes are being set =
to
// the same value.
+ // Nb: We don't have to worry about updating the sec-V-bits table
+ // after these set_vabits2() calls because this code never writes
+ // VA_BITS2_OTHER values.
SizeT i;
for (i =3D 0; i < lenT; i++) {
set_vabits2(a + i, vabits2);
@@ -1159,6 +1170,7 @@
void MC_(copy_address_range_state) ( Addr src, Addr dst, SizeT len )
{
SizeT i, j;
+ UChar vabits2;
=20
DEBUG("MC_(copy_address_range_state)\n");
PROF_EVENT(50, "MC_(copy_address_range_state)");
@@ -1169,14 +1181,22 @@
if (src < dst) {
for (i =3D 0, j =3D len-1; i < len; i++, j--) {
PROF_EVENT(51, "MC_(copy_address_range_state)(loop)");
- set_vabits2( dst+j, get_vabits2( src+j ) );
+ vabits2 =3D get_vabits2( src+j );
+ set_vabits2( dst+j, vabits2 );
+ if (VA_BITS2_OTHER =3D=3D vabits2) {
+ set_sec_vbits8( dst+j, get_sec_vbits8( src+j ) );
+ }
}
}
=20
if (src > dst) {
for (i =3D 0; i < len; i++) {
- PROF_EVENT(51, "MC_(copy_address_range_state)(loop)");
- set_vabits2( dst+i, get_vabits2( src+i ) );
+ PROF_EVENT(52, "MC_(copy_address_range_state)(loop)");
+ vabits2 =3D get_vabits2( src+i );
+ set_vabits2( dst+i, vabits2 );
+ if (VA_BITS2_OTHER =3D=3D vabits2) {
+ set_sec_vbits8( dst+i, get_sec_vbits8( src+i ) );
+ }
}
}
}
Modified: branches/COMPVBITS/memcheck/tests/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/COMPVBITS/memcheck/tests/Makefile.am 2006-02-19 14:05:28 UTC=
(rev 5659)
+++ branches/COMPVBITS/memcheck/tests/Makefile.am 2006-02-20 20:33:27 UTC=
(rev 5660)
@@ -75,6 +75,7 @@
partiallydefinedeq.stdout.exp \
partial_load_ok.vgtest partial_load_ok.stderr.exp partial_load_ok.stder=
r.exp64 \
partial_load_dflt.vgtest partial_load_dflt.stderr.exp partial_load_dflt=
.stderr.exp64 \
+ pdb-realloc.stderr.exp pdb-realloc.vgtest \
pipe.stderr.exp pipe.vgtest \
pointer-trace.vgtest \
pointer-trace.stderr.exp pointer-trace.stderr.exp64 \
@@ -123,7 +124,7 @@
nanoleak new_nothrow \
null_socket oset_test overlap \
partiallydefinedeq \
- partial_load \
+ partial_load pdb-realloc \
pipe pointer-trace \
post-syscall \
realloc1 realloc2 realloc3 \
Added: branches/COMPVBITS/memcheck/tests/pdb-realloc.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/COMPVBITS/memcheck/tests/pdb-realloc.c =
(rev 0)
+++ branches/COMPVBITS/memcheck/tests/pdb-realloc.c 2006-02-20 20:33:27 U=
TC (rev 5660)
@@ -0,0 +1,31 @@
+// This test-case exposes a bug that was present in the compressed V bit
+// handling for a while. The problem was that when
+// copy_address_range_state() copied a VA_BITS2_OTHER value, it failed t=
o
+// also copy the corresponding entry in the sec-V-bits table. Then late=
r on
+// when we searched for the sec-V-bits entry for the copied-to location,=
it
+// failed to find it:
+//
+// Memcheck: mc_main.c:766 (get_sec_vbits8): Assertion 'n' failed.
+// Memcheck: get_sec_vbits8: no node for address 0x4017440 (0x4017441)
+
+#include <stdlib.h>
+
+int main(void)
+{
+ int i, t;
+ char* x =3D malloc(1000);
+
+ // Write some PDBs (partially defined bytes)
+ for (i =3D 0; i < 1000; i++)
+ x[i] &=3D (i & 0xff);
+
+ // realloc them, invoking copy_address_range_state()
+ x =3D realloc(x, 10000);
+
+ // Read the PDBs -- this caused a sec-V-bits lookup failure.
+ for (i =3D 0; i < 1000; i++)
+ t +=3D x[i];
+ =20
+ return 0;
+}
+
Property changes on: branches/COMPVBITS/memcheck/tests/pdb-realloc.c
___________________________________________________________________
Name: svn:executable
+ *
Added: branches/COMPVBITS/memcheck/tests/pdb-realloc.stderr.exp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Added: branches/COMPVBITS/memcheck/tests/pdb-realloc.vgtest
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/COMPVBITS/memcheck/tests/pdb-realloc.vgtest =
(rev 0)
+++ branches/COMPVBITS/memcheck/tests/pdb-realloc.vgtest 2006-02-20 20:33=
:27 UTC (rev 5660)
@@ -0,0 +1,2 @@
+prog: pdb-realloc
+vgopts: -q
|
|
From: Ashley P. <as...@qu...> - 2006-02-20 10:42:40
|
On Sat, 2006-02-18 at 23:13 +0000, sv...@va... wrote: > Log: > First try at an MPI wrappers library. Currently the build system > ignores it - it must be built by hand. Looks interesting, Having read through it I've got a couple of questions for you though (I'll try and keep this short). Why did you use the PMPI functions? I'd have expected the MPI ones to be ok although I guess wrapping weak symbols is different to wrapping normal ones? How is this intended to be used on a practical level?, my understanding is that that function wrappers are executed in the client address space, are you assuming a LD_PRELOAD trick to load this file with the application or is there another way these get loaded? What does the stack trace look like when one of the client checks reports an error, does it include the MPI function name the check is targeted at? The before function could be called from a (P)MPI_Init wrapper, the standard says this is the only function that's safe to call at startup, likewise MPI_Finalize could (should?) do assertion checks that all shadowrequests are free. The standard itself mandates this and some implementations check it but I'm not sure you have wrapped all places these are allocated/destroyed so it's possible you've got a leak here. It's hard to see what the wrappers for Wait/Waitall are going to catch that valgrind wouldn't pick up anyway, they only handle metadata describing comms so should be tracked already by valgrind like any other data in a program. Likewise for Iprobe and OP_create. I'd say MPI_Waitsome, MPI_Alltoall and MPI_Allgather would warrant wrappers as they tend to get used fairly often. The converse is true for MPI_Op_create. I should get a chance to give this code a spin later so I'll be able to give you more feedback then. Ashley, |
|
From: <js...@ac...> - 2006-02-20 09:22:03
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-02-20 02:00:01 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 == 192 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Xin S. <sh...@gm...> - 2006-02-20 08:28:09
|
Thanks a lot, I got it. Xin On 2/20/06, Robert Walsh <rj...@du...> wrote: > > > Hi, Can somebody answer my following question? Or can you give me > > some clues on > > how I can check out from the code? > > This isn't reported because Valgrind doesn't report unitialized > memory until it's used to make a decision or it's passed to a system > call, etc. Please see section 3.3.2 of the documention: > > http://www.valgrind.org/docs/manual/mc-manual.html#mc- > manual.uninitvals > > Regards, > Robert. > |
|
From: Robert W. <rj...@du...> - 2006-02-20 07:11:07
|
> Hi, Can somebody answer my following question? Or can you give me
> some clues on
> how I can check out from the code?
This isn't reported because Valgrind doesn't report unitialized
memory until it's used to make a decision or it's passed to a system
call, etc. Please see section 3.3.2 of the documention:
http://www.valgrind.org/docs/manual/mc-manual.html#mc-
manual.uninitvals
Regards,
Robert.
|
|
From: Xin S. <sh...@gm...> - 2006-02-20 05:53:19
|
Hi, Can somebody answer my following question? Or can you give me some clue= s on how I can check out from the code? Thanks a lot, Xin On 2/18/06, Xin Shen <sh...@gm...> wrote: > > Thanks, a thing I noticed is: > if we define a local variable like: > int x; > > if we do > x++; // no error reported > > if we do > printf( "%d", x ); // unitialized error reported > > If we would be able to track the status of a storage unit regardless a > register or > a memory, why the first case is not reported? > > Thanks, > Xin > > > On 2/17/06, Julian Seward <js...@ac...> wrote: > > > > On Friday 17 February 2006 06:24, Xin Shen wrote: > > > Looks like valgrind doesn't check if a variable in stack is > > initialized > > > except passing into a system call. Even we define a variable inside > > main() > > > function, the variable should exist in the > > > stack, > > > > Not really. On ppc and other cpus with lots of registers, local > > variables > > often live in registers. So whether memcheck complains about them bein= g > > undefined really depends on what the previous status of the register > > was. > > Fortunately gcc is good at pointing out local scalars which might be > > used > > uninitialised, so in practice this is not much of a problem. > > > > J > > > > > so if we pass this varible to the return of main(), the > > > uninitialized error will be reported. > > > > > > Right? > > > Xin > > > > > > > > > Message: 1 > > > > > > > Date: Wed, 15 Feb 2006 17:14:49 -0800 > > > > From: John Reiser <jreiser@BitWagon.com> > > > > Organization: - > > > > To: val...@li... > > > > Subject: Re: [Valgrind-developers] missing unitialized error or > > > > misunderstanding? > > > > > > > > Dave Nomura wrote: > > > > > I was creating an example for a valgrind ppc demo and was > > surprised to > > > > > see that a dereference of an uninitialized global data variable > > did not > > > > > result in an error from valgrind, but when the same variable was > > > > > propagated to exit() via the return value of main() the error was > > > > > detected. Is this a bug or am I misunderstanding what should be > > > > > happening? > > > > > > > > Global data is always initialized; it can never be uninitialized > > > > except via explicit copying from some other uninitialized data. > > > > > > > > If the source code contains no explicit initialization: > > > > int foo; /* at top level (file scope) */ > > > > then as far as guaranteed values are concerned it is equivalent to: > > > > int foo =3D 0; > > > > The first case (no explicit initialization) resides in .bss > > > > which is cleared to zero upon instantiation by the kernel or by > > > > the runtime module loader ld-linux.so. The second case (explicit > > > > initialization) resides in .data, except that some recent compiler > > > > tools put explicit initialization to 0 into .bss because in many > > > > cases it is an optimization (of space in the filesystem). However, > > > > the behavior with respect to data caches at runtime might be > > different. > > > > > > > > -- > > > > > > > > > > > > --__--__-- > > > > > > > > Message: 2 > > > > Date: Thu, 16 Feb 2006 13:52:34 +1100 (EST) > > > > From: Nicholas Nethercote < nj...@cs...> > > > > To: John Reiser <jreiser@BitWagon.com> > > > > cc: val...@li... > > > > Subject: Re: [Valgrind-developers] missing unitialized error or > > > > misunderstanding? > > > > > > > > On Wed, 15 Feb 2006, John Reiser wrote: > > > > >> I was creating an example for a valgrind ppc demo and was > > surprised to > > > > >> see that a dereference of an uninitialized global data variable > > did > > > > >> not result in an error from valgrind, but when the same variable > > was > > > > >> propagated to exit() via the return value of main() the error wa= s > > > > > > >> detected. Is this a bug or am I misunderstanding what should be > > > > >> happening? > > > > > > > > > > Global data is always initialized; it can never be uninitialized > > > > > except via explicit copying from some other uninitialized data. > > > > > > > > John is right. Also, if the global variable became uninitialized > > > > somehow, it's possible that the dereference wasn't complained about > > > > because it didn't > > > > affect the program's behaviour -- ie. it wasn't used as a pointer, > > or as > > > > input to a system call, or in a conditional branch. For example, > > just > > > > copying around uninitialized data doesn't elicit complaints from > > > > Memcheck. See http://www.valgrind.org/docs/memcheck2005.pdf for > > details. > > > > > > > > Nick > > > > |
|
From: <js...@ac...> - 2006-02-20 03:57:35
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-02-20 04:40:00 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 == 197 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) |
|
From: <js...@ac...> - 2006-02-20 03:56:54
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-02-20 03:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 223 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <to...@co...> - 2006-02-20 03:44:07
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-02-20 03:30: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 == 225 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-20 03:30:25
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-02-20 03:15:02 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 == 224 tests, 21 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-20 03:20:15
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-02-20 03:05:16 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 == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-20 03:18:05
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-02-20 03:10:09 GMT Results differ from 24 hours ago Checking out valgrind source tree ... failed Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2006-02-20T03:10:09} valgrind svn: Can't connect to host 'svn.valgrind.org': No route to host ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 5 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Feb 20 03:17:57 2006 --- new.short Mon Feb 20 03:17:58 2006 *************** *** 1,16 **** ! Checking out valgrind source tree ... done ! Configuring valgrind ... done ! Building valgrind ... done ! Running regression tests ... failed ! Regression test results follow ! ! == 245 tests, 5 stderr failures, 1 stdout failure ================= ! memcheck/tests/x86/scalar (stderr) ! memcheck/tests/x86/scalar_supp (stderr) ! memcheck/tests/x86/sse1_memory (stdout) ! none/tests/amd64/faultstatus (stderr) ! none/tests/x86/faultstatus (stderr) ! none/tests/x86/int (stderr) --- 1,7 ---- ! Checking out valgrind source tree ... failed ! Last 20 lines of verbose log follow echo + Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2006-02-20T03:10:09} valgrind + svn: Can't connect to host 'svn.valgrind.org': No route to host |
|
From: Tom H. <th...@cy...> - 2006-02-20 03:14:12
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-02-20 03:00:02 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 == 245 tests, 7 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Julian S. <js...@ac...> - 2006-02-20 01:56:24
|
On Monday 20 February 2006 01:45, David Kimdon wrote:
> It looks like the COMPVBITS branch isn't tracking VEX head, which
> version of VEX should I be using to try out the COMPVBTIS branch?
Yeh, I was trying to shake out a 64-bit bug just now and also had
difficulties on checkout. Eventually I did this:
svn co -r "{2006-01-12}" svn://svn.valgrind.org/valgrind/branches/COMPVBITS \
cvbit
cd cvbit
rm -rf VEX
svn co -r "{2006-01-12}" svn://svn.valgrind.org/vex/trunk VEX
J
|
|
From: David K. <dw...@de...> - 2006-02-20 01:45:44
|
It looks like the COMPVBITS branch isn't tracking VEX head, which version of VEX should I be using to try out the COMPVBTIS branch? Thanks, David |