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
(44) |
2
(9) |
3
(30) |
4
(28) |
5
(42) |
6
(14) |
7
(10) |
|
8
(7) |
9
(8) |
10
(6) |
11
(15) |
12
(13) |
13
(14) |
14
(23) |
|
15
(17) |
16
(10) |
17
(82) |
18
(14) |
19
(21) |
20
(14) |
21
(21) |
|
22
(7) |
23
(13) |
24
(16) |
25
(11) |
26
(11) |
27
(6) |
28
(7) |
|
29
(8) |
30
(13) |
31
(8) |
|
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2006-10-26 01:27:55
|
This bug report was added to the database: http://bugs.kde.org/show_bug.cgi?id=136300 It seems to be addressing the same issue, and there's a patch. I haven't looked at it so I don't know how it compares to your code, but it might be worthwhile looking at it. Nick On Wed, 25 Oct 2006, Dave Nomura wrote: > Julian Seward wrote: >> ---------- >> >> I presume you'll be sending a patch for review at some point? >> > yes, working on it. > > a couple of other issues: > 1. I am dealing with glibc version 2.5 so have already encountered 1 > change needed in the default.supp file. > Do you have any recommendation about how to go about creating a new > glibc-2.5.supp? > start with glibc-2.4 and add stuff as needed? start with an empty file? > > 2. I am making changes to include/vki-ppc{32,64}-linux.h to make > VKI_PAGE_SHIFT and VKI_PAGE_SIZE dependent on initializiation of a > variable. I notice that these files are installed and made available > for public consumption. I initialize the variable that these #defines > depend on in valgrind, but a user that unwittingly uses them in a test > program would be referencing an uninitialized variable. > > How do you think we should handle this? > 1. Change valgrind to use different macros than the VKI_PAGE_* macros? > 2. put some #ifdef's around the ppc VKI_PAGE_* macros, with maybe the 4K > page size as the default, allow the 64K pagesize to be selected by > -DWANT_64K_PAGESIZE, or use the dynamic sizes required by Valgrind > controlled by something like -DWANT_DYNAMIC_PAGESIZE > 3. ??? > >> ---------- >> >> You should think about how to ensure the new functionality doesn't get >> broken in the future -- bearing in mind none (AFAIK) of the available >> test machines are ppc systems with 64k pages. We know from experience >> that functionality which is not automatically tested tends to get >> broken over time. >> >> One effective solution is to run the nightly build system on your own >> 64k-page development box. Another is to add regression tests; although >> I'm not sure how/what they would look like. >> > I'm not sure how I would make specific regression tests either but will > plan on running the regression tests from time to time. > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: <js...@ac...> - 2006-10-26 00:17:49
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2006-10-26 02:00:01 CEST 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 == 220 tests, 14 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-int (stdout) none/tests/ppc64/jm-int (stdout) |
|
From: Dave N. <dc...@us...> - 2006-10-26 00:15:13
|
Julian Seward wrote:
> ----------
>
> I presume you'll be sending a patch for review at some point?
>
yes, working on it.
a couple of other issues:
1. I am dealing with glibc version 2.5 so have already encountered 1
change needed in the default.supp file.
Do you have any recommendation about how to go about creating a new
glibc-2.5.supp?
start with glibc-2.4 and add stuff as needed? start with an empty file?
2. I am making changes to include/vki-ppc{32,64}-linux.h to make
VKI_PAGE_SHIFT and VKI_PAGE_SIZE dependent on initializiation of a
variable. I notice that these files are installed and made available
for public consumption. I initialize the variable that these #defines
depend on in valgrind, but a user that unwittingly uses them in a test
program would be referencing an uninitialized variable.
How do you think we should handle this?
1. Change valgrind to use different macros than the VKI_PAGE_* macros?
2. put some #ifdef's around the ppc VKI_PAGE_* macros, with maybe the 4K
page size as the default, allow the 64K pagesize to be selected by
-DWANT_64K_PAGESIZE, or use the dynamic sizes required by Valgrind
controlled by something like -DWANT_DYNAMIC_PAGESIZE
3. ???
> ----------
>
> You should think about how to ensure the new functionality doesn't get
> broken in the future -- bearing in mind none (AFAIK) of the available
> test machines are ppc systems with 64k pages. We know from experience
> that functionality which is not automatically tested tends to get
> broken over time.
>
> One effective solution is to run the nightly build system on your own
> 64k-page development box. Another is to add regression tests; although
> I'm not sure how/what they would look like.
>
I'm not sure how I would make specific regression tests either but will
plan on running the regression tests from time to time.
|
|
From: Ashley P. <as...@qu...> - 2006-10-25 19:45:11
|
Julian,
This should hopefully be the last one for a while.
Make the signal code xml aware by printing out the correct tags around
the output.
Ashley,
Index: coregrind/m_signals.c
===================================================================
--- coregrind/m_signals.c (revision 6340)
+++ coregrind/m_signals.c (working copy)
@@ -1206,11 +1206,20 @@
}
if (VG_(clo_verbosity) > 1 || (could_core && info->si_code > VKI_SI_USER)) {
- VG_(message)(Vg_UserMsg, "");
- VG_(message)(Vg_UserMsg,
- "Process terminating with default action of signal %d (%s)%s",
- sigNo, signame(sigNo), core ? ": dumping core" : "");
-
+ if (VG_(clo_xml)) {
+ VG_(message)(Vg_UserMsg, "<error>");
+ VG_(message)(Vg_UserMsg, " <tid>%d</tid>", tid);
+ VG_(message)(Vg_UserMsg, " <kind>FatalSignal</kind>");
+ VG_(message)(Vg_UserMsg,
+ " <what>Process terminating with default action of signal %d (%s)%s</what>",
+ sigNo, signame(sigNo), core ? ": dumping core" : "");
+ } else {
+ VG_(message)(Vg_UserMsg, "");
+ VG_(message)(Vg_UserMsg,
+ "Process terminating with default action of signal %d (%s)%s",
+ sigNo, signame(sigNo), core ? ": dumping core" : "");
+ }
+
/* Be helpful - decode some more details about this fault */
if (info->si_code > VKI_SI_USER) {
const Char *event = NULL;
@@ -1276,17 +1285,27 @@
}
if (event != NULL) {
- if (haveaddr)
- VG_(message)(Vg_UserMsg, " %s at address %p",
- event, info->VKI_SIGINFO_si_addr);
- else
- VG_(message)(Vg_UserMsg, " %s", event);
+ if (VG_(clo_xml)) {
+ VG_(message)(Vg_UserMsg, " <event>%s</event>", event);
+ if (haveaddr)
+ VG_(message)(Vg_UserMsg, " <address>%p</address>",
+ info->VKI_SIGINFO_si_addr);
+ } else {
+ if (haveaddr)
+ VG_(message)(Vg_UserMsg, " %s at address %p",
+ event, info->VKI_SIGINFO_si_addr);
+ else
+ VG_(message)(Vg_UserMsg, " %s", event);
+ }
}
}
if (tid != VG_INVALID_THREADID) {
VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
}
+ if (VG_(clo_xml)) {
+ VG_(message)(Vg_UserMsg, "</error>");
+ }
}
if (VG_(is_action_requested)( "Attach to debugger", & VG_(clo_db_attach) )) {
|
|
From: Ashley P. <as...@qu...> - 2006-10-25 19:06:53
|
Attached is the perl script I've been working on for processing the xml files produced my memcheck. It's primary aim is to be able to combine a number of input files and report all of the errors from all of the files in the shortest format possible. This is essential when using valgrind to debug parallel jobs at anything other than a very small cpu count. It does this by taking a number of xml files and as converting them into the "raw" output that valgrind itself would have created. If more than one input file is given it uses the logfilequalifier value (normally set to the rank of the process) to identify which errors occour in which files. It would be nice if this could be incorporated into future releases somehow, along with the regtest patch I sent yesterday which allows this script to used by the memcheck tests. One thing it doesn't do currently but I'm looking at ways to add is to return a error code indicating the presence of errors in the input, this would help with automated testing using valgrind. Ashley, |
|
From: Ashley P. <as...@qu...> - 2006-10-25 18:44:45
|
Attached is a patch to include extra information in the xml output.
This is data which is printed normally but missing from xml, it makes it
tricky to re-form the normal output from the xml if the xml is
incomplete.
Ashley,
ashley:valgrind> svn diff memcheck/
Index: memcheck/mc_malloc_wrappers.c
===================================================================
--- memcheck/mc_malloc_wrappers.c (revision 6341)
+++ memcheck/mc_malloc_wrappers.c (working copy)
@@ -791,9 +791,7 @@
if (VG_(clo_verbosity) == 0)
return;
- if (VG_(clo_xml))
- return;
-
+
/* Count memory still in use. */
VG_(HT_ResetIter)(MC_(malloc_list));
while ( (mc = VG_(HT_Next)(MC_(malloc_list))) ) {
@@ -801,6 +799,21 @@
nbytes += mc->size;
}
+ if (VG_(clo_xml)) {
+ VG_(message)(Vg_UserMsg,
+ "<malloc_use>");
+ VG_(message)(Vg_UserMsg,
+ " <at_exit><bytes>%lu</bytes><blocks>%lu</blocks></at_exit>",
+ nbytes, nblocks);
+ VG_(message)(Vg_UserMsg,
+ " <total><allocs>%lu</allocs><frees>%lu</frees><bytes>%lu</bytes></total>",
+ cmalloc_n_mallocs,
+ cmalloc_n_frees, cmalloc_bs_mallocd);
+ VG_(message)(Vg_UserMsg,
+ "</malloc_use>");
+ return;
+ }
+
VG_(message)(Vg_UserMsg,
"malloc/free: in use at exit: %,lu bytes in %,lu blocks.",
nbytes, nblocks);
Index: memcheck/mc_leakcheck.c
===================================================================
--- memcheck/mc_leakcheck.c (revision 6341)
+++ memcheck/mc_leakcheck.c (working copy)
@@ -938,6 +938,23 @@
"To see them, rerun with: --show-reachable=yes");
}
}
+ if (VG_(clo_verbosity) > 0 && VG_(clo_xml)) {
+ VG_(message)(Vg_UserMsg, "<leak_summary>");
+ VG_(message)(Vg_UserMsg, " <lost>");
+ VG_(message)(Vg_UserMsg, " <definitely><bytes>%lu</bytes><blocks>%lu</blocks></definitely>",
+ MC_(bytes_leaked), blocks_leaked );
+ if (blocks_indirect > 0)
+ VG_(message)(Vg_UserMsg, " <indirectly><bytes>%lu</bytes><blocks>%lu</blocks></indirectly>",
+ MC_(bytes_indirect), blocks_indirect );
+ VG_(message)(Vg_UserMsg, " <possibly><bytes>%lu</bytes><blocks>%lu</blocks></possibly>",
+ MC_(bytes_dubious), blocks_dubious );
+ VG_(message)(Vg_UserMsg, " </lost>");
+ VG_(message)(Vg_UserMsg, " <reachable><bytes>%lu</bytes><blocks>%lu</blocks></reachable>",
+ MC_(bytes_reachable), blocks_reachable );
+ VG_(message)(Vg_UserMsg, " <suppressed><bytes>%lu</bytes><blocks>%lu</blocks></suppressed>",
+ MC_(bytes_suppressed), blocks_suppressed );
+ VG_(message)(Vg_UserMsg, "</leak_summary>");
+ }
VG_(free) ( lc_shadows );
VG_(free) ( lc_markstack );
|
|
From: <js...@ac...> - 2006-10-25 14:49:42
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-10-25 09:00:02 BST 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 == 214 tests, 12 stderr failures, 7 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/jm-int (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <raf...@gm...> - 2006-10-25 12:54:18
|
On 10/24/06, Julian Seward <js...@ac...> wrote: > > Yes, please submit a bug report. It would also be good to have > a C program which reproduced the problem, if you can construct > one. Just compile the attached files with "g++ -O2 -g main.cpp test.cpp -o test". It will print the warning ==13355== Conditional jump or move depends on uninitialised value(s) ==13355== at 0x400568: f(my_s*) (test.cpp:9) ==13355== by 0x400591: main (main.cpp:11) With the change you proposed, no warning is printed. Should I submit a bug report anyway? > J Thanks, Rafael |
|
From: <raf...@gm...> - 2006-10-25 12:44:54
|
> Hmm, hang on. I just dealt with this one 5 days ago.
>
> Firstly, what V version is this with? What gcc version? And
> what program were you running on V to get this error?
3.2.1 and svn. gcc 4.1.2. I was running psi. The error is in this Qt4
qxml.cpp check:
-------------
if (atEnd()) {
-------------
atEnd is inlined into
------------------------
ushort u = c.unicode()
if((u|0x0001) == 0xffff) {
------------------------
> Anyway, can you try the following (on a 3.2.1 tree):
>
> In VEX/priv/guest-amd64/ghelper.c function
> guest_amd64_spechelper find the case for DECW (will be obvious,
> near line 1188) and after it add this:
>
> /*---------------- INCW ----------------*/
>
> if (isU64(cc_op, AMD64G_CC_OP_INCW) && isU64(cond, AMD64CondZ)) {
> /* 16-bit inc, then Z --> test dst == 0 */
> return unop(Iop_1Uto64,
> binop(Iop_CmpEQ64,
> binop(Iop_Shl64,cc_dep1,mkU8(48)),
> mkU64(0)));
> }
>
> Rebuild (make clean ; make ; make install) and try again. Does
> that fix it?
I have tried it on svn rev 6340. It works! Thank you very much.
> If that doesn't work try instead with AMD64CondNZ and Iop_CmpNE64.
>
> J
>
Rafael
|
|
From: Tom H. <to...@co...> - 2006-10-25 02:46:15
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-10-25 03:30:06 BST 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 == 246 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-10-25 02:28:30
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-10-25 03:10:06 BST 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 == 274 tests, 22 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_creat (stderr) none/tests/fdleak_dup (stderr) none/tests/fdleak_dup2 (stderr) none/tests/fdleak_fcntl (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/fdleak_open (stderr) none/tests/fdleak_pipe (stderr) none/tests/fdleak_socketpair (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/rlimit_nofile (stderr) |
|
From: Tom H. <th...@cy...> - 2006-10-25 02:21:55
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-10-25 03:00:02 BST 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 == 276 tests, 15 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (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) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Julian S. <js...@ac...> - 2006-10-25 01:04:58
|
Hi. If anyone out there has a Core 2 machine I would be interested in seeing the resulting numbers from 'make perf' in either a 3.2.1 or svn trunk tree, preferably from a run when the machine was otherwise quiet. Also the same for P4 Northwood and P4 Prescott would be interesting. I'm mostly interested in 32-bit mode numbers at this point. Of course amd64/ppc performance is important too, but what I'm interested in is gathering data for/against the theory that the memcheck's performance is determined more by L2 cache size than by any other microarchitectural factor (eg, how good your branch predictor is). Thanks, J |
|
From: <js...@ac...> - 2006-10-25 00:17:35
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2006-10-25 02:00:01 CEST 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 == 220 tests, 14 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-int (stdout) none/tests/ppc64/jm-int (stdout) |
|
From: Julian S. <js...@ac...> - 2006-10-24 21:52:17
|
> > ------------------------------------
> > movl (%rdi), %eax
> > orl $1, %eax
> > incw %ax
> > je .L17
> > ------------------------------------
Hmm, hang on. I just dealt with this one 5 days ago.
Firstly, what V version is this with? What gcc version? And
what program were you running on V to get this error?
Anyway, can you try the following (on a 3.2.1 tree):
In VEX/priv/guest-amd64/ghelper.c function
guest_amd64_spechelper find the case for DECW (will be obvious,
near line 1188) and after it add this:
/*---------------- INCW ----------------*/
if (isU64(cc_op, AMD64G_CC_OP_INCW) && isU64(cond, AMD64CondZ)) {
/* 16-bit inc, then Z --> test dst == 0 */
return unop(Iop_1Uto64,
binop(Iop_CmpEQ64,
binop(Iop_Shl64,cc_dep1,mkU8(48)),
mkU64(0)));
}
Rebuild (make clean ; make ; make install) and try again. Does
that fix it?
If that doesn't work try instead with AMD64CondNZ and Iop_CmpNE64.
J
|
|
From: <sv...@va...> - 2006-10-24 21:43:45
|
Author: sewardj
Date: 2006-10-24 22:43:38 +0100 (Tue, 24 Oct 2006)
New Revision: 6341
Log:
Make the hashing in VG_(record_ExeContext) 64-bit clean and more
robust. Also incrementally rearrange the hash chains during searches.
Modified:
trunk/coregrind/m_execontext.c
Modified: trunk/coregrind/m_execontext.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
--- trunk/coregrind/m_execontext.c 2006-10-23 21:24:55 UTC (rev 6340)
+++ trunk/coregrind/m_execontext.c 2006-10-24 21:43:38 UTC (rev 6341)
@@ -185,6 +185,13 @@
on the returned ExeContext* values themselves. Inspired by Hugs's
Text type. =20
*/
+static inline UWord ROLW ( UWord w, Int n )
+{
+ Int bpw =3D 8 * sizeof(UWord);
+ w =3D (w << n) | (w >> (bpw-n));
+ return w;
+}
+
ExeContext* VG_(record_ExeContext) ( ThreadId tid )
{
Int i;
@@ -194,7 +201,13 @@
ExeContext* new_ec;
ExeContext* list;
UInt n_ips;
+ ExeContext *prev2, *prev;
=20
+ static UInt ctr =3D 0;
+
+ vg_assert(sizeof(void*) =3D=3D sizeof(UWord));
+ vg_assert(sizeof(void*) =3D=3D sizeof(Addr));
+
init_ExeContext_storage();
vg_assert(VG_(clo_backtrace_size) >=3D 1 &&
VG_(clo_backtrace_size) <=3D VG_DEEPEST_BACKTRACE);
@@ -208,15 +221,19 @@
hash =3D 0;
for (i =3D 0; i < n_ips; i++) {
hash ^=3D ips[i];
- hash =3D (hash << 29) | (hash >> 3);
+ hash =3D ROLW(hash, 19);
}
+ if (0) VG_(printf)("hash 0x%lx ", hash);
hash =3D hash % N_EC_LISTS;
+ if (0) VG_(printf)("%lu\n", hash);
=20
/* And (the expensive bit) look a matching entry in the list. */
=20
ec_searchreqs++;
=20
- list =3D ec_list[hash];
+ prev2 =3D NULL;
+ prev =3D NULL;
+ list =3D ec_list[hash];
=20
while (True) {
if (list =3D=3D NULL) break;
@@ -229,11 +246,22 @@
}
}
if (same) break;
- list =3D list->next;
+ prev2 =3D prev;
+ prev =3D list;
+ list =3D list->next;
}
=20
if (list !=3D NULL) {
- /* Yay! We found it. */
+ /* Yay! We found it. Once every 8 searches, move it one step
+ closer to the start of the list to make future searches
+ cheaper. */
+ if (prev2 && prev && 0 =3D=3D ((ctr++) & 7)) {
+ vg_assert(prev2->next =3D=3D prev);
+ vg_assert(prev->next =3D=3D list);
+ prev2->next =3D list;
+ prev->next =3D list->next;
+ list->next =3D prev;
+ }
return list;
}
=20
|
|
From: Julian S. <js...@ac...> - 2006-10-24 21:41:39
|
Yes, please submit a bug report. It would also be good to have a C program which reproduced the problem, if you can construct one.=20 J On Tuesday 24 October 2006 21:41, Rafael Esp=EDndola wrote: > Generally when compiling a ((short|1) =3D=3D constant) compression, gcc > generates this code: > > --------------------------------------- > movl (%rdi), %eax > orl $1, %eax > cmpw $43, %ax > je .L17 > --------------------------------------- > > This works correctly on valgrind even if the second half of eax is > undefined (cmpw doesn't use it). > > But if the constant is 0xffff, the generated code is > > ------------------------------------ > movl (%rdi), %eax > orl $1, %eax > incw %ax > je .L17 > ------------------------------------ > > In this case valgrind prints the warning > ------------------------------------ > Conditional jump or move depends on uninitialised value(s) > ------------------------------------ > > But the Z flag doesn't depend on the high part of eax. So the jump > doesn't depend on uninitialized values. > > Should I submit a bug report? Where should I look in the code to try > to fix this? > > Thanks, > Rafael > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <raf...@gm...> - 2006-10-24 20:41:16
|
Generally when compiling a ((short|1) == constant) compression, gcc
generates this code:
---------------------------------------
movl (%rdi), %eax
orl $1, %eax
cmpw $43, %ax
je .L17
---------------------------------------
This works correctly on valgrind even if the second half of eax is
undefined (cmpw doesn't use it).
But if the constant is 0xffff, the generated code is
------------------------------------
movl (%rdi), %eax
orl $1, %eax
incw %ax
je .L17
------------------------------------
In this case valgrind prints the warning
------------------------------------
Conditional jump or move depends on uninitialised value(s)
------------------------------------
But the Z flag doesn't depend on the high part of eax. So the jump
doesn't depend on uninitialized values.
Should I submit a bug report? Where should I look in the code to try
to fix this?
Thanks,
Rafael
|
|
From: Ashley P. <as...@qu...> - 2006-10-24 17:50:04
|
Hi,
I've attached a patch I use for testing the xml output of valgrind. The
concept is simple enough, if enabled it inserts adds --xml=yes to the
valgrind command line a "prefilter" command to convert from xml back to
the raw valgrind output. This is then checked for errors in the normal
way.
To go along with this I'm developing a stand-alone perl utility which
converts from xml output back into raw output. I'll be submitting this
shortly.
Currently I see a number of extra failures when testing this way, a
number of which represent bugs in the xml output of memcheck, mostly of
the form where memcheck prints a error message but doesn't put the
correct xml tags around it.
Ashley,
Errors I get normally:
memcheck/tests/badjump (stderr)
memcheck/tests/badpoll (stderr)
memcheck/tests/buflen_check (stderr)
memcheck/tests/describe-block (stderr)
memcheck/tests/execve (stderr)
memcheck/tests/execve2 (stderr)
memcheck/tests/fwrite (stderr)
memcheck/tests/match-overrun (stderr)
memcheck/tests/pointer-trace (stderr)
memcheck/tests/stack_switch (stderr)
memcheck/tests/supp_unknown (stderr)
memcheck/tests/writev (stderr)
memcheck/tests/x86/scalar (stderr)
memcheck/tests/x86/scalar_exit_group (stderr)
memcheck/tests/x86/scalar_supp (stderr)
memcheck/tests/xml1 (stderr)
Errors I get using xml output.
memcheck/tests/addressable (stderr)
memcheck/tests/badjump (stderr)
memcheck/tests/badjump2 (stderr)
memcheck/tests/badpoll (stderr)
memcheck/tests/brk (stderr)
memcheck/tests/brk2 (stderr)
memcheck/tests/buflen_check (stderr)
memcheck/tests/describe-block (stderr)
memcheck/tests/erringfds (stderr)
memcheck/tests/execve (stderr)
memcheck/tests/execve2 (stderr)
memcheck/tests/fwrite (stderr)
memcheck/tests/leak-0 (stderr)
memcheck/tests/leak-cycle (stderr)
memcheck/tests/leak-pool-0 (stderr)
memcheck/tests/leak-pool-1 (stderr)
memcheck/tests/leak-pool-2 (stderr)
memcheck/tests/leak-pool-3 (stderr)
memcheck/tests/leak-pool-4 (stderr)
memcheck/tests/leak-pool-5 (stderr)
memcheck/tests/leak-regroot (stderr)
memcheck/tests/leak-tree (stderr)
memcheck/tests/malloc3 (stderr)
memcheck/tests/match-overrun (stderr)
memcheck/tests/mempool (stderr)
memcheck/tests/nanoleak (stderr)
memcheck/tests/new_override (stderr)
memcheck/tests/partial_load_dflt (stderr)
memcheck/tests/partial_load_ok (stderr)
memcheck/tests/partiallydefinedeq (stderr)
memcheck/tests/pointer-trace (stderr)
memcheck/tests/post-syscall (stderr)
memcheck/tests/sh-mem (stderr)
memcheck/tests/sigaltstack (stderr)
memcheck/tests/sigkill (stderr)
memcheck/tests/sigprocmask (stderr)
memcheck/tests/stack_switch (stderr)
memcheck/tests/supp_unknown (stderr)
memcheck/tests/toobig-allocs (stderr)
memcheck/tests/trivialleak (stderr)
memcheck/tests/writev (stderr)
memcheck/tests/x86/scalar (stderr)
memcheck/tests/x86/scalar_exit_group (stderr)
memcheck/tests/x86/scalar_fork (stderr)
memcheck/tests/x86/scalar_supp (stderr)
memcheck/tests/x86/scalar_vfork (stderr)
memcheck/tests/xml1 (stderr)
ashley:valgrind> svn diff Makefile.am tests/vg_regtest.in
Index: Makefile.am
===================================================================
--- Makefile.am (revision 6340)
+++ Makefile.am (working copy)
@@ -64,6 +64,9 @@
regtest: check
@PERL@ tests/vg_regtest $(TOOLS)
+regtestxml: check
+ @PERL@ tests/vg_regtest --xml-tool=xml2raw.pl $(TOOLS)
+
## Preprend @PERL@ because tests/vg_per isn't executable
perf: check
@PERL@ perf/vg_perf perf
Index: tests/vg_regtest.in
===================================================================
--- tests/vg_regtest.in (revision 6340)
+++ tests/vg_regtest.in (working copy)
@@ -93,11 +93,13 @@
my $tmp="vg_regtest.tmp.$$";
# Test variables
-my $vgopts; # valgrind options
+my $vgopts; # valgrind options (per test)
+my @vgextraopts; # valgrind options (global)
my $prog; # test prog
my $args; # test prog args
-my $stdout_filter; # filter program to run stdout results file through
-my $stderr_filter; # filter program to run stderr results file through
+my $stdout_filter; # filter program to run stdout results file through (per test)
+my $stderr_filter; # filter program to run stderr results file through (per test)
+my $stderr_prefilter; # filter program to run strerr results file through (global)
my $prereq; # prerequisite test to satisfy before running test
my $posttest; # check command after running test
my $cleanup; # cleanup command to run
@@ -161,6 +163,9 @@
$valgrind = $1;
} elsif ($arg =~ /^--valgrind-lib=(.*)$/) {
$valgrind_lib = $1;
+ } elsif ($arg =~ /^--xml-tool=(.*)$/) {
+ $stderr_prefilter = validate_program("$tests_dir/auxprogs" , $1, 1, 1);
+ push(@vgextraopts,"--xml=yes");
} else {
die $usage;
}
@@ -308,6 +313,9 @@
# VALGRIND_LIB_INNER in case this Valgrind was configured with
# --enable-inner.
my $tool=determine_tool();
+ if ( $tool eq "memcheck" ) {
+ $vgopts .= " @vgextraopts";
+ }
mysystem("VALGRIND_LIB=$valgrind_lib VALGRIND_LIB_INNER=$valgrind_lib "
. "$valgrind --command-line-only=yes --memcheck:leak-check=no "
. "--tool=$tool $extraopts $vgopts "
@@ -323,6 +331,12 @@
@stdout_exps = ( "/dev/null" ) if (0 == scalar @stdout_exps);
do_diffs($fullname, $name, "stdout", \@stdout_exps);
+ # Run the pre-filter.
+ if ( $tool eq "memcheck" and defined $stderr_prefilter ) {
+ mysystem("$stderr_prefilter $name.stderr.out > $tmp");
+ rename($tmp, "$name.stderr.out");
+ }
+
# Filter stderr
mysystem("$stderr_filter < $name.stderr.out > $tmp");
rename($tmp, "$name.stderr.out");
|
|
From: Dave N. <dc...@us...> - 2006-10-24 15:52:55
|
RHEL5 will include Valgrind 3.2.1 Julian Seward wrote: > On Monday 23 October 2006 21:49, Dave Nomura wrote: > >> I am reporting a problem to Red Hat that their RHEL5 release is missing >> the ppc64-linux diretory in /usr/lib/valgrind. >> > > ppc64-linux is only supported by V >= 3.2.0. If they are shipping 3.1.X > then you would only expect to see ppc32-linux/. > > > |
|
From: <js...@ac...> - 2006-10-24 14:45:25
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-10-24 09:00:01 BST 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 == 214 tests, 12 stderr failures, 7 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/jm-int (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Julian S. <js...@ac...> - 2006-10-24 12:53:50
|
On Monday 23 October 2006 21:49, Dave Nomura wrote: > I am reporting a problem to Red Hat that their RHEL5 release is missing > the ppc64-linux diretory in /usr/lib/valgrind. ppc64-linux is only supported by V >= 3.2.0. If they are shipping 3.1.X then you would only expect to see ppc32-linux/. > For the x86 family under what circumstances would I expect the > corresponding <arch>64-linux directory in /usr/lib/valgrind, and what is > it's name? The name is amd64-linux. You would expect to get it if V was built on a 64-bit capable x86 CPU -- it is the configure script that decides what variants to build. J |
|
From: Tom H. <to...@co...> - 2006-10-24 07:22:34
|
In message <59e...@ma...>
cat...@gm... wrote:
> The problem i am facing is i am not able to trace the execution of valgrind
> into the VEX/priv/guest-x86/toIR.c file . Its not even compiling the file
> when i change the code inside the file. Can somebody please help me in this
> ?
Doing a make in the top level doesn't always rebuild VEX properly - just
cd into VEX and do a make there then come back up and do a make.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Vikas <cat...@gm...> - 2006-10-24 04:37:03
|
Hi , I am trying to get the x86 instructions executed for any x86 binary on a x86/Redhat linux platform . The VG_(disBB)( which basically does the dispatch) uses the disInstr_X86_WRK to translate the x86 instructions one at a time and dumping them into the UCOde block . The code inside the disInstr_X86_WRK function at VEX/priv/guest-x86/toIR.c will store the x86 instructions at guest_code and the offset address for x86 instruction is stored in delta . The problem i am facing is i am not able to trace the execution of valgrind into the VEX/priv/guest-x86/toIR.c file . Its not even compiling the file when i change the code inside the file. Can somebody please help me in this ? Waiting for your replies , Regards, Vikas |
|
From: Tom H. <to...@co...> - 2006-10-24 02:45:45
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-10-24 03:30:05 BST 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 == 246 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |