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
(16) |
|
3
(9) |
4
(8) |
5
(9) |
6
(10) |
7
(14) |
8
(10) |
9
(7) |
|
10
(14) |
11
(19) |
12
(22) |
13
(18) |
14
(20) |
15
(10) |
16
(12) |
|
17
(13) |
18
(7) |
19
(12) |
20
(13) |
21
(9) |
22
(12) |
23
(6) |
|
24
(5) |
25
(5) |
26
(6) |
27
(7) |
28
(9) |
29
(13) |
30
(21) |
|
From: Julian S. <js...@ac...> - 2006-09-01 13:18:28
|
I can see that some info like that would be helpful, but I'm concerned
that it might be a case of fixing the symptoms (and/or adding a fix
which makes sense only for eg x86 and not generally).
What I think would be helpful is to make a concise, semi-formal
statement of the problem. I think this would help by showing how this
relates to standard compiler concepts of liveness and reachability.
In particular I'd like to find a solution which gives accurate results
and which works well even in the presence of optimised code, which AIUI
Omega currently doesn't.
My initial thoughts at such a statement are:
- keep track of all allocated blocks
- keep track of all potential roots. Potential roots at any
time are
* the words in all currently accessible memory, plus the words
in the registers
BUT
only those for which the next event is a read
- If some part of the address space disappears, that can be thought of
as a write.
- If a write (to a potential root) happens, and that destroys the last
pointer to a particular block, then we can complain at that point
of a leak.
- However, that may be too late. (as per current example)
What we really want to find is something along the lines of
'dead writes' (to registers and memory). A dead write puts a value
into that storage location which is never read, only overwritten
(or the storage location goes out of scope, which is equivalent).
Perhaps it should be that a leak is reported at a dead write of
the last pointer to a block. Or something. Anyway, the general
idea is: if you can characterise the problem in terms of dataflow
and liveness, perhaps it becomes possible to build an implementation
which is robust to ABI changes, compiler optimisation, and across
different platforms.
The above ideas are half-baked; don't take the details too literally.
---
Another thing that would help (perhaps the same thing, really)
is to give a very precise specification of what the tool is intended
to do.
Originally I had the impression that it was "find where the last pointer
to block X is overwritten"; but when looked at under a magnifying glass
it's clear this can lead to error reports which point to some location
in the code flow which may be arbitrarily far after the place where you
really wanted to report the error. So (and I think this is the crux
of the problem) how do you precisely specify those program points where
you *do* want to report an error?
J
On Thursday 31 August 2006 21:18, Bryan Meredith wrote:
> Julian,
>
> looking in readdwarf.c and storage.c, I think I can put a patch together
> that adds a flag into DiSym in order to indicate "no return", "return"
> or "unknown" (for when the debug isn't there and it's time to hit a
> fall-back method - this would also be the default value).
>
> Would it be of interest? I don't want to spend time doing this if its
> not going to go in (pending code review etc of course).
>
> My idea is to extend the read_unitinfo_dwarf2 function by a) passing in
> the seginfo pointer in order to give access to the symtab and b) to
> parse out TAG_subprogram entries.
>
> Basically, a void function has no type (AT_type) entry. Once a
> subprogram is fully parsed, search_one_symtab can be used to find the
> related DiSym and then update the entry from the default "unknown".
>
> Bryan
>
> Bryan Meredith wrote:
> > Julian Seward wrote:
> >>> Looking at the two programs side by side, I think the real crux of it
> >>> is the differing epilog code. I think I am falling over trying to
> >>> detect when there is a value being returned through the accumulator.
> >>
> >> This sounds like a dataflow/liveness problem. So, let me unwind
> >> one more level. Why do you want to know whether the accumulator
> >> contains a live vs dead value at the point the function returns?
> >> What are you going to do with that info?
> >>
> >> J
> >
> > Julian,
> >
> > that's exactly the problem. If the accumulator holds a pointer to a
> > memory block and is live, it should be left alone and tracked out of the
> > function. If it is dead, it should be culled as the function exits,
> > possibly generating a leak report if it is the final pointer to that
> > block.
> >
> > If the pointer is dead but is left until it is over-written, the
> > location of the leak report is inaccurate.
> >
> > The ability to detect the dead value allows function scope related
> > checking for leaks. As an example (this is scope2.c in the test
> > directory):
> >
> > #include <stdlib.h>
> >
> > static void func1(void)
> > {
> > char *pointer = 0;
> >
> > pointer = malloc(64); /* Line 7 */
> >
> > return;
> > } /* Leak report Line 10 */
> >
> > int main(int argc, char *argv[])
> > {
> > func1();
> >
> > return 0; /* Line 16 */
> > }
> >
> > At line 7, the malloc() call returns the pointer in the accumulator
> > which is then also saved into the stack variable "pointer". As the
> > function exits, the stack unwinds, removing the reference in "pointer"
> > but the accumulator will still hold a reference. If the accumulator is
> > detected as being dead, a leak report will be generated at line 10 as we
> > remove the reference it is holding and discover it is the last one. If
> > we don't invalidate the accumulator, we get the leak report at line 16
> > instead when the reference is overwritten by 0 in order to be returned
> > by main().
> >
> > A report at line 16 is not only inferior to a report at line 10, it is
> > not going to provide the clarity that Omega should supply in it's goal
> > to assist in tracking down memory leaks: a report at line 10 makes it
> > pretty obvious that something went out of scope whilst a report at line
> > 16 will leave most people scratching their heads.
> >
> > It's pretty fundamental to the whole thing which is why I could do with
> > a robust method for determining when to cull registers on exit and when
> > to leave them alone - the ABI is simply not enough.
> >
> > Hope that explains it,
> > Bryan
> >
> > -------------------------------------------------------------------------
> > 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-09-01 11:01:39
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-09-01 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 == 207 tests, 10 stderr failures, 6 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/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (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: <js...@ac...> - 2006-09-01 04:06:57
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-09-01 04:30:01 BST 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 == 237 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-01 03:21:25
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-01 03:00:08 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 == 268 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/mempool (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) none/tests/tls (stdout) |
|
From: Tom H. <to...@co...> - 2006-09-01 02:45:30
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-01 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 == 239 tests, 5 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/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Julian S. <js...@ac...> - 2006-09-01 02:45:25
|
Should I push this (and/or r6044) into 3.2.1 ?
J
On Thursday 31 August 2006 20:29, sv...@va... wrote:
> Author: weidendo
> Date: 2006-08-31 20:29:13 +0100 (Thu, 31 Aug 2006)
> New Revision: 6043
>
> Log:
> callgrind: Fix warning about malformed creator line in annotate script
>
> This also changes the default filename (if not given) to callgrind.out.*
>
> Modified:
> trunk/callgrind/callgrind_annotate.in
>
>
> Modified: trunk/callgrind/callgrind_annotate.in
> ===================================================================
> --- trunk/callgrind/callgrind_annotate.in 2006-08-31 11:08:59 UTC (rev
> 6042) +++ trunk/callgrind/callgrind_annotate.in 2006-08-31 19:29:13 UTC
> (rev 6043) @@ -100,6 +100,7 @@
> my $cmd = "";
>
> # Info on the profiled process.
> +my $creator = "";
> my $pid = "";
> my $part = "";
> my $thread = "";
> @@ -310,10 +311,12 @@
> }
>
> if ($input_file eq "") {
> - $input_file = (<cachegrind.out*>)[0];
> + $input_file = (<callgrind.out*>)[0];
> if (!defined $input_file) {
> - $input_file = "cachegrind.out";
> + $input_file = (<cachegrind.out*>)[0];
> }
> +
> + (defined $input_file) or die($usage);
> print "Reading data from '$input_file'...\n";
> }
> }
> @@ -403,6 +406,7 @@
> else { $desc .= "$dline\n"; }
> }
> elsif (/^cmd:\s+(.*)$/) { $cmd = $1; }
> + elsif (/^creator:\s+(.*)$/) { $creator = $1; }
> elsif (/^positions:\s+(.*)$/) {
> my $positions = $1;
> $has_line = ($positions =~ /line/);
> @@ -670,6 +674,11 @@
> sub print_options ()
> {
> print($fancy);
> + print "Profile data file '$input_file'";
> + if ($creator ne "") { print " (creator: $creator)"; }
> + print "\n";
> +
> + print($fancy);
> print($desc);
> my $target = $cmd;
> if ($pid ne "") {
>
>
> -------------------------------------------------------------------------
> 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: Tom H. <th...@cy...> - 2006-09-01 02:25:28
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-01 03:10: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 == 266 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-01 02:24:19
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-01 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccgBSkHf.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgBSkHf.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.32326/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.32326/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccbpx6z9.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbpx6z9.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.32326/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.32326/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.32326/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Sep 1 03:19:38 2006 --- new.short Fri Sep 1 03:24:14 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccbpx6z9.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbpx6z9.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccgBSkHf.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgBSkHf.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-01 02:20:29
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-01 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 == 266 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leakotron (stdout) 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/mremap (stderr) none/tests/mremap2 (stdout) |