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
(16) |
2
(10) |
3
(7) |
4
(8) |
5
(8) |
|
6
(11) |
7
(6) |
8
(14) |
9
(9) |
10
(6) |
11
(5) |
12
(5) |
|
13
(5) |
14
(8) |
15
(8) |
16
(12) |
17
(7) |
18
(7) |
19
(6) |
|
20
(7) |
21
(6) |
22
(6) |
23
(9) |
24
(13) |
25
(8) |
26
(6) |
|
27
(6) |
28
(6) |
29
(6) |
30
(7) |
31
(6) |
|
|
|
From: <sv...@va...> - 2007-05-24 23:14:42
|
Author: njn
Date: 2007-05-25 00:14:41 +0100 (Fri, 25 May 2007)
New Revision: 6750
Log:
Add a comment with a definitive account of when Memcheck does (and does not,
but should do) undefined value checks.
Modified:
trunk/memcheck/mc_translate.c
Modified: trunk/memcheck/mc_translate.c
===================================================================
--- trunk/memcheck/mc_translate.c 2007-05-24 20:47:10 UTC (rev 6749)
+++ trunk/memcheck/mc_translate.c 2007-05-24 23:14:41 UTC (rev 6750)
@@ -50,6 +50,61 @@
2005 USENIX Annual Technical Conference (General Track),
Anaheim, CA, USA, April 10-15, 2005.
+
+ ----
+
+ Here is as good a place as any to record exactly when V bits are and
+ should be checked, why, and what function is responsible.
+
+
+ Memcheck complains when an undefined value is used:
+
+ 1. In the condition of a conditional branch. Because it could cause
+ incorrect control flow, and thus cause incorrect externally-visible
+ behaviour. [mc_translate.c:complainIfUndefined]
+
+ 2. As an argument to a system call, or as the value that specifies
+ the system call number. Because it could cause an incorrect
+ externally-visible side effect. [mc_translate.c:mc_pre_reg_read]
+
+ 3. As the address in a load or store. Because it could cause an
+ incorrect value to be used later, which could cause externally-visible
+ behaviour (eg. via incorrect control flow or an incorrect system call
+ argument) [complainIfUndefined]
+
+ 4. As the target address of a branch. Because it could cause incorrect
+ control flow. [complainIfUndefined]
+
+ 5. As an argument to setenv, unsetenv, or putenv. Because it could put
+ an incorrect value into the external environment.
+ [mc_replace_strmem.c:VG_WRAP_FUNCTION_ZU(*, *env)]
+
+ 6. As the index in a GETI or PUTI operation. I'm not sure why... (njn).
+ [complainIfUndefined]
+
+ 7. As an argument to the VALGRIND_CHECK_MEM_IS_DEFINED and
+ VALGRIND_CHECK_VALUE_IS_DEFINED client requests. Because the user
+ requested it. [in memcheck.h]
+
+
+ Memcheck also complains, but should not, when an undefined value is used:
+
+ 8. As the shift value in certain SIMD shift operations (but not in the
+ standard integer shift operations). This inconsistency is due to
+ historical reasons.) [complainIfUndefined]
+
+
+ Memcheck does not complain, but should, when an undefined value is used:
+
+ 9. As an input to a client request. Because the client request may
+ affect the visible behaviour -- see bug #144362 for an example
+ involving the malloc replacements in vg_replace_malloc.c and
+ VALGRIND_NON_SIMD_CALL* requests, where an uninitialised argument
+ isn't identified. That bug report also has some info on how to solve
+ the problem. [valgrind.h:VALGRIND_DO_CLIENT_REQUEST]
+
+
+ In practice, 1 and 2 account for the vast majority of cases.
*/
/*------------------------------------------------------------*/
|
|
From: <sv...@va...> - 2007-05-24 20:47:14
|
Author: weidendo
Date: 2007-05-24 21:47:10 +0100 (Thu, 24 May 2007)
New Revision: 6749
Log:
callgrind_annotate: Fix a warning
Port a fix for ""Possible precedence problem" from
cachegrind/cg_annotate, see r1713.
Modified:
trunk/callgrind/callgrind_annotate.in
Modified: trunk/callgrind/callgrind_annotate.in
===================================================================
--- trunk/callgrind/callgrind_annotate.in 2007-05-24 20:42:41 UTC (rev 6748)
+++ trunk/callgrind/callgrind_annotate.in 2007-05-24 20:47:10 UTC (rev 6749)
@@ -867,7 +867,7 @@
if ($summary_CC->[$sort_order[$i]] >0) {
$prop = $prop / $summary_CC->[$sort_order[$i]];
}
- $reached_all_thresholds &= ($prop >= $thresholds[$i]);
+ $reached_all_thresholds &&= ($prop >= $thresholds[$i]);
}
last if $reached_all_thresholds;
|
|
From: <sv...@va...> - 2007-05-24 20:42:42
|
Author: weidendo Date: 2007-05-24 21:42:41 +0100 (Thu, 24 May 2007) New Revision: 6748 Log: Callgrind manual: Fix typo Modified: trunk/callgrind/docs/cl-manual.xml Modified: trunk/callgrind/docs/cl-manual.xml =================================================================== --- trunk/callgrind/docs/cl-manual.xml 2007-05-24 19:24:23 UTC (rev 6747) +++ trunk/callgrind/docs/cl-manual.xml 2007-05-24 20:42:41 UTC (rev 6748) @@ -395,7 +395,7 @@ analysis of your code harder. This is because inclusive costs for calls inside of a cycle are meaningless. The definition of inclusive cost, ie. self cost of a function plus inclusive cost - of its callers, needs a topological order among functions. For + of its callees, needs a topological order among functions. For cycles, this does not hold true: callees of a function in a cycle include the function itself. Therefore, KCachegrind does cycle detection and skips visualization of any inclusive cost for calls inside |
|
From: <sv...@va...> - 2007-05-24 19:24:26
|
Author: weidendo Date: 2007-05-24 20:24:23 +0100 (Thu, 24 May 2007) New Revision: 6747 Log: Callgrind manual: rewriting start of section about avoding cycles This hopefully makes the whole issue with cycles easier to understand. And no, this does not get rid of the description of cycles, carefully crafted by Julian ;-) Modified: trunk/callgrind/docs/cl-manual.xml Modified: trunk/callgrind/docs/cl-manual.xml =================================================================== --- trunk/callgrind/docs/cl-manual.xml 2007-05-24 18:04:42 UTC (rev 6746) +++ trunk/callgrind/docs/cl-manual.xml 2007-05-24 19:24:23 UTC (rev 6747) @@ -385,30 +385,65 @@ a third function H is called from inside S and calls back into S, then H is also part of the cycle and should be included in S.</para> - <para>If a call chain goes multiple times around inside a cycle, - with profiling, you can not distinguish event counts coming from the - first, second or subsequent rounds. - Thus, it makes no sense to attach any inclusive - cost to a call among functions inside of one cycle. - If "A > B" appears multiple times in a call chain, you - have no way to partition the one big sum of all appearances of "A > - B". Thus, for profile data presentation, all functions of a cycle are - seen as one big virtual function.</para> + <para>Recursion is quite usual in programs, and therefore, cycles + sometimes appear in the call graph output of Callgrind. However, + the title of this chapter should raise two questions: What is bad + about cycles which makes you want to avoid them? And: How can + cycles be avoided without changing program code?</para> - <para>Unfortunately, if you have an application using some callback - mechanism (like any GUI program), or even with normal polymorphism (as - in OO languages like C++), it's quite possible to get large cycles. - As it is often impossible to say anything about performance behaviour - inside of cycles, it is useful to introduce some mechanisms to avoid - cycles in call graphs. This is done by treating the same - function in different ways, depending on the current execution - context, either by giving them different names, or by ignoring calls to - functions.</para> + <para>Cycles are not bad in itself, but tend to make performance + analysis of your code harder. This is because inclusive costs + for calls inside of a cycle are meaningless. The definition of + inclusive cost, ie. self cost of a function plus inclusive cost + of its callers, needs a topological order among functions. For + cycles, this does not hold true: callees of a function in a cycle include + the function itself. Therefore, KCachegrind does cycle detection + and skips visualization of any inclusive cost for calls inside + of cycles. Further, all functions in a cycle are collapsed into artifical + functions called like <computeroutput>Cycle 1</computeroutput>.</para> - <para>There is an option to ignore calls to a function with - <option><xref linkend="opt.fn-skip"/>=funcprefix</option>. For - example you - usually do not want to see the trampoline functions in the PLT sections + <para>Now, when a program exposes really big cycles (as is + true for some GUI code, or in general code using event or callback based + programming style), you loose the nice property to let you pinpoint + the bottlenecks by following call chains from + <computeroutput>main()</computeroutput>, guided via + inclusive cost. In addition, KCachegrind looses its ability to show + interesting parts of the call graph, as it uses inclusive costs to + cut off uninteresting areas.</para> + + <para>Despite the meaningless of inclusive costs in cycles, the big + drawback for visualization motivates the possibility to temporarely + switch off cycle detection in KCachegrind, which can lead to + misguiding visualization. However, often cycles appear because of + unlucky superposition of independant call chains in a way that + the profile result will see a cycle. Neglecting uninteresting + calls with very small measured inclusive cost would break these + cycles. In such cases, incorrect handling of cycles by not detecting + them still gives meaningful profiling visualization.</para> + + <para>It has to be noted that currently, <command>callgrind_annotate</command> + does not do any cycle detection at all. For program executions with function + recursion, it e.g. can print nonsense inclusive costs way above 100%.</para> + + <para>After describing why cycles are bad for profiling, it is worth + talking about cycle avoidance. The key insight here is that symbols in + the profile data do not have to exactly match the symbols found in the + program. Instead, the symbol name could encode additional information + from the current execution context such as recursion level of the + current function, or even some part of the call chain leading to the + function. While encoding of additional information into symbols is + quite capable of avoiding cycles, it has to be used carefully to not cause + symbol explosion. The latter imposes large memory requirement for Callgrind + with possible out-of-memory conditions, and big profile data files.</para> + + <para>A further possibility to avoid cycles in Callgrinds profile data + output is to simply leave out given functions in the call graph. Of course, this + also skips any call information from and to an ignored function, and thus can + break a cycle. Candidates for this typically are dispatcher functions in event + driven code. The option to ignore calls to a function is + <option><xref linkend="opt.fn-skip"/>=funcprefix</option>. Aside from + possibly breaking cycles, this is used in Callgrind to skip + trampoline functions in the PLT sections for calls to functions in shared libraries. You can see the difference if you profile with <option><xref linkend="opt.skip-plt"/>=no</option>. If a call is ignored, its cost events will be propagated to the |
|
From: Vikas <cat...@gm...> - 2007-05-24 19:03:21
|
hi , did u install valgrind as a root or as a user in your machine ??? if u installed it as a user then u have to give prefix otherwise it gives errors while installing itself i guess .... thanks, vikas On 5/24/07, Suman#SS185 Aluvala <alu...@ho...> wrote: > > Hi Friends, > I am new valgrind user, i am getting errors when i am trying to install in > my Red Hat Linux pc > > when i am typing "valgrind ls -l" i am getting error as > "valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No > such > file or directory" > > when i am typing "valgrind -d" i am getting the information > --14674:1:debuglog DebugLog system started by Stage 1, level 1 logging > requested > --14674:1:launcher no tool requested, defaulting to 'memcheck' > --14674:1:launcher no client specified, defaulting platform to 'x86-linux' > --14674:1:launcher launching /usr/local/lib/valgrind/x86-linux/memcheck > valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No > such > file or directory > > > And i didn't used any --PREFIX either during configuration or else > installation. > > Please help me in resolving this issue...... > > Thanks in advance... friends > Suman#SS185 > > _________________________________________________________________ > Catch the complete World Cup coverage with MSN > http://content.msn.co.in/Sports/Cricket/Default.aspx > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: <sv...@va...> - 2007-05-24 18:04:44
|
Author: weidendo Date: 2007-05-24 19:04:42 +0100 (Thu, 24 May 2007) New Revision: 6746 Log: Callgrind format: Note about event names in the example The added paragraph was triggered by a question on the mailing list. Modified: trunk/callgrind/docs/cl-format.xml Modified: trunk/callgrind/docs/cl-format.xml =================================================================== --- trunk/callgrind/docs/cl-format.xml 2007-05-23 21:58:33 UTC (rev 6745) +++ trunk/callgrind/docs/cl-format.xml 2007-05-24 18:04:42 UTC (rev 6746) @@ -49,6 +49,12 @@ <sect2 id="cl-format.overview.example1" xreflabel="Simple Example"> <title>Simple Example</title> +<para>The event names in the following example are quite arbitrary, and are not +related to event names used by Callgrind. Especially, cycle counts matching +real processors probably will never be generated by any Valgrind tools, as these +are bound to simulations of simple machine models for acceptable slowdown. +However, any profiling tool could use the format described in this chapter.</para> + <para> <screen>events: Cycles Instructions Flops fl=file.f @@ -548,4 +554,4 @@ </sect1> -</chapter> \ No newline at end of file +</chapter> |
|
From: <js...@ac...> - 2007-05-24 14:45:27
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-05-24 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 == 219 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == 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/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/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: Suman#SS185 A. <alu...@ho...> - 2007-05-24 14:22:04
|
Hi Friends, I am new valgrind user, i am getting errors when i am trying to install in my Red Hat Linux pc when i am typing "valgrind ls -l" i am getting error as "valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory" when i am typing "valgrind -d" i am getting the information --14674:1:debuglog DebugLog system started by Stage 1, level 1 logging requested --14674:1:launcher no tool requested, defaulting to 'memcheck' --14674:1:launcher no client specified, defaulting platform to 'x86-linux' --14674:1:launcher launching /usr/local/lib/valgrind/x86-linux/memcheck valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory And i didn't used any --PREFIX either during configuration or else installation. Please help me in resolving this issue...... Thanks in advance... friends Suman#SS185 _________________________________________________________________ Catch the complete World Cup coverage with MSN http://content.msn.co.in/Sports/Cricket/Default.aspx |
|
From: Tom H. <th...@cy...> - 2007-05-24 02:31:25
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-05-24 03:15:03 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 == 256 tests, 27 stderr failures, 1 stdout failure, 0 posttest failures == 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-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/long_namespace_xml (stderr) memcheck/tests/match-overrun (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/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-05-24 02:23:30
|
Nightly build on dellow ( x86_64, Fedora Core 6 ) started at 2007-05-24 03:10: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 == 292 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-05-24 02:17:27
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2007-05-24 03:05:04 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 == 292 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) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-05-24 02:10:55
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-05-24 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 == 294 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) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2007-05-24 00:17:07
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-05-24 02:00:01 CEST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 226 tests, 6 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/res_search (stdout) ================================================= == 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 == 226 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu May 24 02:08:08 2007 --- new.short Thu May 24 02:16:57 2007 *************** *** 8,10 **** ! == 226 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) --- 8,10 ---- ! == 226 tests, 6 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) *************** *** 17,18 **** --- 17,19 ---- none/tests/mremap2 (stdout) + none/tests/res_search (stdout) |