Re: [Valgrind-developers] valgrind: r7080 - trunk/massif
On Fri, Nov 02, 2007 at 04:12:50AM +, [EMAIL PROTECTED] wrote: > Author: njn > -static UInt clo_heap_admin = 8; > + // clo_heap_admin is deliberately a word-sized type. At one point it was > + // a UInt, but this caused problems on 64-bit machines when it was > + // multiplied by a small negative number and then promoted to a > + // word-sized type -- it ended up with a value of 4.2 billion. Sigh. > +static SizeT clo_heap_admin = 8; > this is really odd ... the code in update_heap_stats() did this: (unsigned long) = (unsigned long) + (unsigned int) * (signed int); while the actual multiplication is signed, the result is taken to be unsigned and is accordingly zero-extended in the promotion. you converted this to (unsigned long) = (unsigned long) + (unsigned long) * (signed int); which is about the right thing to do. however, for *way* more clarity and less bloat i'd suggest writing the actual expression as update_alloc_stats(heap_szB_delta + (SizeT)clo_heap_admin*n_heap_blocks_delta); instead of making the variable bigger. btw, in ms_post_clo_init() you'll get a warning, because, duh, an unsigned value cannot be smaller than zero. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
Re: [Valgrind-developers] Alternative set of locking functions for thrcheck
It works, many thanks!
--kcc
On 11/1/07, Julian Seward <[EMAIL PROTECTED]> wrote:
>
> On Thursday 01 November 2007 14:26, Konstantin Serebryany wrote:
> > Hi Julian,
> >
> > What shall I do if my .so has no soname?
> > What if my locking primitives reside in the main binary?
>
> That's ok. Use "NONE". See readelf.c:904.
>
> J
>
> >
> > Thanks,
> >
> > --kcc
> >
> > On 10/31/07, Julian Seward <[EMAIL PROTECTED]> wrote:
> > > On Wednesday 31 October 2007 16:01, Konstantin Serebryany wrote:
> > > > Hi,
> > > >
> > > > I am trying to use thrcheck from THRCHECK branch.
> > > >
> > > > My program uses pthread_create to create threads, however it does
> not
> > >
> > > use
> > >
> > > > pthread_mutex_lock/unclock for locking -- it has its own set of
> locking
> > > > primitives.
> > > >
> > > > Is it possible to enhance thrcheck to handle user-settable
> lock/unlock
> > > > primitives?
> > >
> > > Yes, it is already possible. Look in tc_intercepts.c
> > > and look at the functions pthreadZumutexZulock and
> > > pthreadZumutexZuunlock. You need to make something like these
> > > (add them to tc_intercepts.c to keep your life simple).
> > >
> > > In the lock wrapper, the important components are
> > >
> > > VALGRIND_GET_ORIG_FN(fn);
> > >
> > > CALL_FN_W_W(ret, fn, mutex);
> > >
> > > if (ret == 0 /*success*/) {
> > >DO_CREQ_v_W(_VG_USERREQ__TC_PTHREAD_MUTEX_LOCK_POST,
> > >pthread_mutex_t*,mutex);
> > >
> > > It is this last part that notifies the tool that you acquired
> > > the lock.
> > >
> > > In the unlock wrapper, the important components are
> > >
> > >VALGRIND_GET_ORIG_FN(fn);
> > >
> > >DO_CREQ_v_W(_VG_USERREQ__TC_PTHREAD_MUTEX_UNLOCK_PRE,
> > >pthread_mutex_t*,mutex);
> > >
> > >CALL_FN_W_W(ret, fn, mutex);
> > >
> > > So in the lock wrapper you don't notify Thrcheck you have the lock
> > > until after the CALL_FN_W_W (the real lock call) succeeds.
> > > Conversely in the unlock wrapper you tell thrcheck you have
> > > released the lock before you really have released it.
> > >
> > > You will need to know the soname of the object containing your
> > > lock/unlock functions in order that you can write the magic PTH_FUNC
> > > wrapper. Study PTH_FUNC and QT4_FUNC. You can find the soname of
> > > xyz.so by doing "readelf -a xyz.so | grep soname".
> > >
> > > Use --trace-redir=yes and/or -v to find out whether your wrappers
> > > are actually getting called or not.
> > >
> > > J
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
Re: [Valgrind-developers] can x86 valgrind run on a PPC client program?
On Fri, Nov 02, 2007 at 08:56:08AM -0700, Dave Nomura wrote: > Is it possible to run an x86 valgrind on a PPC program? If so, how > would you do it? > so you want a cross-executing valgrind ... while i think vex would have no major problems with it (give or take some minor adjustments), i'm pretty sure nobody has written a syscall translation layer, and i guess it's unlikely that anybody will. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
[Valgrind-developers] can x86 valgrind run on a PPC client program?
Is it possible to run an x86 valgrind on a PPC program? If so, how would you do it? -- Dave Nomura LTC Linux Power Toolchain - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
[Valgrind-developers] valgrind: r7082 - in trunk: . massif
Author: njn
Date: 2007-11-02 20:44:57 + (Fri, 02 Nov 2007)
New Revision: 7082
Log:
Change ms_print to ms_print.in, link it into the build/install system.
Added:
trunk/massif/ms_print.in
Removed:
trunk/massif/ms_print
Modified:
trunk/configure.in
trunk/massif/Makefile.am
Modified: trunk/configure.in
===
--- trunk/configure.in 2007-11-02 04:17:28 UTC (rev 7081)
+++ trunk/configure.in 2007-11-02 20:44:57 UTC (rev 7082)
@@ -983,6 +983,7 @@
massif/tests/Makefile
massif/perf/Makefile
massif/docs/Makefile
+ massif/ms_print
lackey/Makefile
lackey/tests/Makefile
lackey/docs/Makefile
Modified: trunk/massif/Makefile.am
===
--- trunk/massif/Makefile.am2007-11-02 04:17:28 UTC (rev 7081)
+++ trunk/massif/Makefile.am2007-11-02 20:44:57 UTC (rev 7082)
@@ -2,6 +2,8 @@
SUBDIRS += perf
+bin_SCRIPTS = ms_print
+
noinst_PROGRAMS =
if VGP_X86_LINUX
noinst_PROGRAMS += massif-x86-linux vgpreload_massif-x86-linux.so
Deleted: trunk/massif/ms_print
===
--- trunk/massif/ms_print 2007-11-02 04:17:28 UTC (rev 7081)
+++ trunk/massif/ms_print 2007-11-02 20:44:57 UTC (rev 7082)
@@ -1,649 +0,0 @@
-#! /usr/bin/perl
-
-####
-##--- Massif's results printer ms_print.in ---##
-####
-
-# This file is part of Massif, a Valgrind tool for profiling memory
-# usage of programs.
-#
-# Copyright (C) 2007-2007 Nicholas Nethercote
-# [EMAIL PROTECTED]
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of the
-# License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
-# 02111-1307, USA.
-#
-# The GNU General Public License is contained in the file COPYING.
-
-use warnings;
-use strict;
-
-#
-# Global variables, main data structures
-#
-
-# Command line of profiled program.
-my $cmd;
-
-# Time unit used in profile.
-my $time_unit;
-
-# Threshold dictating what percentage an entry must represent for us to
-# bother showing it.
-my $threshold = 1.0;
-
-# Graph x and y dimensions.
-my $graph_x = 72;
-my $graph_y = 20;
-
-# Input file name
-my $input_file = undef;
-
-# Tmp file name.
-my $tmp_file = "ms_print.tmp.$$";
-
-# Version number (XXX: change it when I convert this file to ms_print.in)
-my $version = "XXX";# "@VERSION@";
-
-# Args passed, for printing.
-my $ms_print_args;
-
-# Usage message.
-my $usage = <
-
- options for the user, with defaults in [ ], are:
--h --help show this message
--v --version show version
---threshold= significance threshold, in percent [$threshold]
---x= graph width, in columns; min=4, max=1000 [72]
---y= graph height, in rows; min=4, max=1000 [20]
-
- ms_print is Copyright (C) 2007-2007 Nicholas Nethercote.
- and licensed under the GNU General Public License, version 2.
- Bug reports, feedback, admiration, abuse, etc, to: [EMAIL PROTECTED]
-
-END
-;
-
-# Used in various places of output.
-my $fancy= '-' x 80;
-my $fancy_nl = $fancy . "\n";
-
-# Returns 0 if the denominator is 0.
-sub safe_div_0($$)
-{
-my ($x, $y) = @_;
-return ($y ? $x / $y : 0);
-}
-
-#-
-# Argument and option handling
-#-
-sub process_cmd_line()
-{
-my @files;
-
-# Grab a copy of the arguments, for printing later.
-for my $arg (@ARGV) {
-$ms_print_args .= " $arg"; # The arguments.
-}
-
-for my $arg (@ARGV) {
-
-# Option handling
-if ($arg =~ /^-/) {
-
-# --version
-if ($arg =~ /^-v$|^--version$/) {
-die("ms_print-$version\n");
-
-# --threshold=X (tolerates a trailing '%')
-} elsif ($arg =~ /^--threshold=([\d\.]+)%?$/) {
-$threshold = $1;
-($1 >= 0 && $1 <=
[Valgrind-developers] valgrind: r7083 - trunk/massif/perf
Author: njn Date: 2007-11-02 20:47:53 + (Fri, 02 Nov 2007) New Revision: 7083 Log: Fix a Makefile issue that I think caused automated testing to fail on 'alvis' last night. I don't no why it worked on the other machines, must be an automake version thing. Modified: trunk/massif/perf/Makefile.am Modified: trunk/massif/perf/Makefile.am === --- trunk/massif/perf/Makefile.am 2007-11-02 20:44:57 UTC (rev 7082) +++ trunk/massif/perf/Makefile.am 2007-11-02 20:47:53 UTC (rev 7083) @@ -2,7 +2,7 @@ # For AM_FLAG_M3264_PRI include $(top_srcdir)/Makefile.flags.am -EXTRA_DIST = $(noinst_SCRIPTS) \ +EXTRA_DIST = \ many-xpts.vgperf check_PROGRAMS = \ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
Re: [Valgrind-developers] valgrind: r7080 - trunk/massif
On Fri, 2 Nov 2007, Oswald Buddenhagen wrote: > this is really odd ... That's what I thought :) > the code in update_heap_stats() did this: > (unsigned long) = (unsigned long) + (unsigned int) * (signed int); > while the actual multiplication is signed, the result is taken to be > unsigned and is accordingly zero-extended in the promotion. > you converted this to > (unsigned long) = (unsigned long) + (unsigned long) * (signed int); > which is about the right thing to do. however, for *way* more clarity > and less bloat i'd suggest writing the actual expression as > update_alloc_stats(heap_szB_delta + > (SizeT)clo_heap_admin*n_heap_blocks_delta); > instead of making the variable bigger. I thought about following your suggestion, but your solution only fixes that particular expression, whereas making it a SizeT avoids the possibility of it happening elsewhere. Thanks for the explanation, that's basically what I thought was happening but you explained it more clearly than I had understood it in my head. Nick - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
Re: [Valgrind-developers] can x86 valgrind run on a PPC client program?
On Fri, 2 Nov 2007, Dave Nomura wrote: > Is it possible to run an x86 valgrind on a PPC program? If so, how > would you do it? Maybe if you run Valgrind on QEMU (or another dynamic binary translator) running the PPC program? Otherwise I can't see how it would work. Nick - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
Re: [Valgrind-developers] valgrind: r7080 - trunk/massif
On Sat, Nov 03, 2007 at 07:59:38AM +1100, Nicholas Nethercote wrote: > On Fri, 2 Nov 2007, Oswald Buddenhagen wrote: >> for *way* more clarity >> and less bloat i'd suggest writing the actual expression as >> update_alloc_stats(heap_szB_delta + >> (SizeT)clo_heap_admin*n_heap_blocks_delta); >> instead of making the variable bigger. > > I thought about following your suggestion, but your solution only > fixes that particular expression, whereas making it a SizeT avoids the > possibility of it happening elsewhere. > hmm, but by this logic you have to promote every single variable that is ever used in an offset or size calculation to [S]SizeT, no matter how oversized it seems ... i guess one simply has to keep such issues in mind when doing C. probably *the* reason why Java simply dropped unsigned types. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
Re: [Valgrind-developers] can x86 valgrind run on a PP C client program?
On Friday 02 November 2007 18:44, Oswald Buddenhagen wrote: > On Fri, Nov 02, 2007 at 08:56:08AM -0700, Dave Nomura wrote: > > Is it possible to run an x86 valgrind on a PPC program? If so, how > > would you do it? > > so you want a cross-executing valgrind ... > while i think vex would have no major problems with it (give or take > some minor adjustments), i'm pretty sure nobody has written a syscall > translation layer, That's true. One of the vex design goals was to support cross-translation although that's never been used so far. But anyway, why would you want to do such a bizarre thing? Why not just valgrindify your ppc app on a ppc box? J - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
[Valgrind-developers] valgrind: r7084 - trunk/massif
Author: njn Date: 2007-11-02 21:44:02 + (Fri, 02 Nov 2007) New Revision: 7084 Log: Update todo notes Modified: trunk/massif/ms_main.c Modified: trunk/massif/ms_main.c === --- trunk/massif/ms_main.c 2007-11-02 20:47:53 UTC (rev 7083) +++ trunk/massif/ms_main.c 2007-11-02 21:44:02 UTC (rev 7084) @@ -36,7 +36,25 @@ // documentation // - write documentation // - make --threshold and --peak-inaccuracy fractional -// - do filename properly, clean up Valgrind-wide log file naming mess +// - do filename properly, clean up Valgrind-wide log file naming mess. +// Expected behaviour: +// - Main log file: +// default --> stderr +// --log-file=X --> X. +// --log-file-exactly=X --> X +// --log-file-qualifier=QUAL--> [error] +// --log-file=X --log-file-qualifier=QUAL --> X.$QUAL +// - Massif out file: +// default --> cachegrind.out. +// --cg-out-file=X --> X. +// --cg-out-file-exactly=X --> X +// --cg-out-file-qualifier=QUAL --> [error] +// --cg-out-file=X --cg-out-file-qualifier=QUAL --> X.$QUAL +// - Likewise for Cachegrind, but with --cg-out/cg.out. +// - And in cg_annotate, remove the -- option. +// - Likewise for Callgrind, but with --cl-out/cl.out (?) +// - And don't create .1, .2 etc suffixed files. +// // - currently recording asked-for sizes of heap blocks, not actual sizes. // Should add the difference to heap-admin, and change heap-admin name to // something else (heap-extra?). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
[Valgrind-developers] Consistent naming options for output [was: Re: valgrind: r7084 - trunk/massif]
On Friday 02 November 2007, [EMAIL PROTECTED] wrote: > Author: njn > +// - Massif out file: > +// default --> cachegrind.out. > +// --cg-out-file=X --> X. > +// --cg-out-file-exactly=X --> X > +// --cg-out-file-qualifier=QUAL --> [error] > +// --cg-out-file=X --cg-out-file-qualifier=QUAL --> X.$QUAL > +// - Likewise for Cachegrind, but with --cg-out/cg.out. > +// - And in cg_annotate, remove the -- option. > +// - Likewise for Callgrind, but with --cl-out/cl.out (?) > +// - And don't create .1, .2 etc suffixed files. Hi Nick, cool, that you want to solve this mess in a consistent way. I am all for it. I am just not sure if the above is flexible enough. Eg. in callgrind, I can have output triggered from different threads, as well as multiple outputs. I think that allowing for a format pattern would be a good way. In this format pattern, we could allow for sequences to be substituted: %pof running process %tproducing this output %T tool name %c counter to be incremented on each output I do not understand the benefit of QUAL above. Do I understand correctly, and you specify the name of an environment variable here that is substituted in the file name? Why can you not just say --cg-out-file=X.$QUAL (ie. the substitution is done by the shell at exec time)? With %T, we could generalize the options among the tools, e.g. by just using "--out-file=". However. This does not really work for callgrind :-( To get the current behavior of callgrind, there is the need for four (!) such patterns for different contexts: 1) termination without separate counters per thread: %T.out.%p 2) termination withseparate counters per thread: %T.out.%p-%t 3) dumping in the middle without seperate c.p.t. : %T.out.%p.%c 4) " with ": %T.out.%p.%c-%t I am open for any suggestions to unify this mess into just one pattern. The bad thing is that KCachegrind depends on this to some extend: When running KCachegrind on the generated output from termination, it searches for any further outputs with suffixes. However, I want to get rid of this because it is quite a confusing behavior. Josef - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
[Valgrind-developers] 2007-11-03 02:00:01 CET nightly build (g5, SuSE 10.1, ppc970)
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-11-03 02:00:01 CET 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 == 255 tests, 11 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates(stdout) memcheck/tests/leak-cycle(stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) massif/tests/culling1(stderr) massif/tests/culling2(stderr) massif/tests/deep-C (stderr) massif/tests/peak2 (stderr) massif/tests/realloc (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap(stderr) none/tests/mremap2 (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 == 255 tests, 11 stderr failures, 2 stdout failures, 6 post failures == memcheck/tests/deep_templates(stdout) memcheck/tests/leak-cycle(stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) massif/tests/basic (post) massif/tests/culling1(stderr) massif/tests/culling2(stderr) massif/tests/custom_alloc(post) massif/tests/deep-C (stderr) massif/tests/deep-D (post) massif/tests/ignoring(post) massif/tests/peak(post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (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 Sat Nov 3 02:08:30 2007 --- new.short Sat Nov 3 02:17:48 2007 *** *** 8,10 ! == 255 tests, 11 stderr failures, 2 stdout failures, 6 post failures == memcheck/tests/deep_templates(stdout) --- 8,10 ! == 255 tests, 11 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates(stdout) *** *** 13,24 memcheck/tests/pointer-trace (stderr) - massif/tests/basic (post) massif/tests/culling1(stderr) massif/tests/culling2(stderr) - massif/tests/custom_alloc(post) massif/tests/deep-C (stderr) - massif/tests/deep-D (post) - massif/tests/ignoring(post) - massif/tests/peak(post) massif/tests/peak2 (stderr) - massif/tests/peak2 (post) massif/tests/realloc (stderr) --- 13,18 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
[Valgrind-developers] 2007-11-03 03:00:03 GMT nightly build (gill, x86_64, Fedora Core 2)
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-11-03 03:00:03 GMT Results unchanged 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 then mv -f ".deps/long-time.Tpo" ".deps/long-time.Po"; else rm -f ".deps/long-time.Tpo"; exit 1; fi long-time.c: In function `main': long-time.c:15: warning: ISO C90 forbids mixed declarations and code long-time.c:18: warning: ISO C90 forbids mixed declarations and code gcc -Winline -Wall -Wshadow -g -m64 -Wno-long-long -Wdeclaration-after-statement -o long-time long-time.o if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../include -I../../coregrind -I../../include -I../../VEX/pub -g -O2 -MT new-cpp.o -MD -MP -MF ".deps/new-cpp.Tpo" -c -o new-cpp.o new-cpp.cpp; \ then mv -f ".deps/new-cpp.Tpo" ".deps/new-cpp.Po"; else rm -f ".deps/new-cpp.Tpo"; exit 1; fi new-cpp.cpp: In function `int main()': new-cpp.cpp:20: error: invalid use of undefined type `struct main()::s' new-cpp.cpp:20: error: forward declaration of `struct main()::s' new-cpp.cpp:20: error: ISO C++ forbids defining types within new make[4]: *** [new-cpp.o] Error 1 make[4]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind/massif/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind/massif/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind/massif' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind' make: *** [check] Error 2 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
[Valgrind-developers] 2007-11-03 03:15:02 GMT nightly build (alvis, i686, Red Hat 7.3)
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-11-03 03:15:02 GMT 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 fi gcc -Winline -Wall -Wshadow -g -m32 -Wno-long-long -o long-time long-time.o if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../include -I../../coregrind -I../../include -I../../VEX/pub -g -O2 -MT new-cpp.o -MD -MP -MF ".deps/new-cpp.Tpo" \ -c -o new-cpp.o `test -f 'new-cpp.cpp' || echo './'`new-cpp.cpp; \ then mv -f ".deps/new-cpp.Tpo" ".deps/new-cpp.Po"; \ else rm -f ".deps/new-cpp.Tpo"; exit 1; \ fi new-cpp.cpp: In function `int main()': new-cpp.cpp:20: invalid use of undefined type `struct main()::s' new-cpp.cpp:20: forward declaration of `struct main()::s' new-cpp.cpp:20: ISO C++ forbids defining types within new make[4]: *** [new-cpp.o] Error 1 make[4]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind/massif/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind/massif/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind/massif' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind' make: *** [check] Error 2 = == Results from 24 hours ago == = Checking out valgrind source tree ... done Configuring valgrind ... failed Last 20 lines of verbose log follow echo A valgrind/VEX/quote.txt A valgrind/VEX/Makefile A valgrind/VEX/LICENSE.README U valgrind/VEX Checked out external at revision 1791. Checked out revision 7079. Configuring valgrind ... cd valgrind && ./autogen.sh && ./configure --prefix=/tmp/vgtest/2007-11-03/Inst running: aclocal running: autoheader running: automake -a configure.in: installing `./install-sh' configure.in: installing `./mkinstalldirs' configure.in: installing `./missing' configure.in:116: installing `./config.guess' configure.in:116: installing `./config.sub' auxprogs/Makefile.am: installing `./compile' auxprogs/Makefile.am: installing `./depcomp' EXTRA_DIST: variable `noinst_SCRIPTS' is used but `noinst_SCRIPTS' is undefined error: while running 'automake -a' = == Difference between 24 hours ago and now == = *** old.short Sat Nov 3 03:16:11 2007 --- new.short Sat Nov 3 03:21:22 2007 *** *** 2,25 Checking out valgrind source tree ... done !Configuring valgrind ... failed Last 20 lines of verbose log follow echo ! A valgrind/VEX/quote.txt ! A valgrind/VEX/Makefile ! A valgrind/VEX/LICENSE.README ! U valgrind/VEX ! Checked out external at revision 1791. ! ! Checked out revision 7079. !Configuring valgrind ... cd valgrind && ./autogen.sh && ./configure --prefix=/tmp/vgtest/2007-11-03/Inst ! running: aclocal ! running: autoheader ! running: automake -a ! configure.in: installing `./install-sh' ! configure.in: installing `./mkinstalldirs' ! configure.in: installing `./missing' ! configure.in:116: installing `./config.guess' ! configure.in:116: installing `./config.sub' ! auxprogs/Makefile.am: installing `./compile' ! auxprogs/Makefile.am: installing `./depcomp' ! EXTRA_DIST: variable `noinst_SCRIPTS' is used but `noinst_SCRIPTS' is undefined ! error: while running 'automake -a' --- 2,27 Checking out valgrind source tree ... done !Configuring valgrind ... done !Building valgrind ... done !Running regression tests ... failed Last 20 lines of verbose log follow echo ! fi ! gcc -Winline -Wall -Wshadow -g -m32 -Wno-long-long -o long-time long-time.o ! if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../include -I../../coregrind -I../../include -I../../VEX/pub -g -O2 -MT new-cpp.o -MD -MP -MF ".deps/new-cpp.Tpo" \ ! -c -o new-cpp.o `test -f 'new-cpp.cpp' || echo './'`new-cpp.cpp; \ ! then mv -f ".deps/new-cpp.Tpo" ".deps/new-cpp.Po"; \ ! else rm -f ".deps/new-cpp.Tpo"; exit 1; \ ! fi ! new-cpp.cpp: In function `int main()': ! new-cpp.cpp:20: invalid use of undefined type `struct main()::s' ! new-cpp.cpp:20: forward declaration of `struct main()::s' ! new-cpp.cpp:20: ISO C++ forbids defining types within new ! make[4]: *** [new-cpp.o] Error 1 ! make[4]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind/massif/tests' ! make[3]: *** [check-am] Error 2 ! make[3]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind/massif/tests' ! make[2]: *** [check-recursive] Error 1 ! make[2]: Leaving directory `/tmp/vgtest/2007-11-03/valgrind/massif' ! make[1]: *** [check-recursive] Error
[Valgrind-developers] 2007-11-03 03:05:06 GMT nightly build (lloyd, x86_64, Fedora 7)
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-11-03 03:05:06 GMT 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 == 320 tests, 4 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns(stdout) memcheck/tests/x86/scalar(stderr) memcheck/tests/xml1 (stderr) none/tests/mremap(stderr) none/tests/mremap2 (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 == 320 tests, 5 stderr failures, 2 stdout failures, 8 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns(stdout) memcheck/tests/x86/scalar(stderr) memcheck/tests/xml1 (stderr) massif/tests/basic (post) massif/tests/custom_alloc(post) massif/tests/deep-D (post) massif/tests/ignoring(post) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) massif/tests/peak(post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) none/tests/mremap(stderr) none/tests/mremap2 (stdout) = == Difference between 24 hours ago and now == = *** old.short Sat Nov 3 03:13:02 2007 --- new.short Sat Nov 3 03:23:16 2007 *** *** 8,10 ! == 320 tests, 5 stderr failures, 2 stdout failures, 8 post failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ! == 320 tests, 4 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) *** *** 13,23 memcheck/tests/xml1 (stderr) - massif/tests/basic (post) - massif/tests/custom_alloc(post) - massif/tests/deep-D (post) - massif/tests/ignoring(post) - massif/tests/new-cpp (post) - massif/tests/overloaded-new (post) - massif/tests/peak(post) - massif/tests/peak2 (stderr) - massif/tests/peak2 (post) none/tests/mremap(stderr) --- 13,14 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
[Valgrind-developers] 2007-11-03 03:10:03 GMT nightly build (dellow, x86_64, Fedora 7)
Nightly build on dellow ( x86_64, Fedora 7 ) started at 2007-11-03 03:10:03 GMT 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 == 320 tests, 4 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns(stdout) memcheck/tests/x86/scalar(stderr) memcheck/tests/xml1 (stderr) none/tests/mremap(stderr) none/tests/mremap2 (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 == 320 tests, 5 stderr failures, 4 stdout failures, 8 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns(stdout) memcheck/tests/x86/scalar(stderr) memcheck/tests/xml1 (stderr) massif/tests/basic (post) massif/tests/custom_alloc(post) massif/tests/deep-D (post) massif/tests/ignoring(post) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) massif/tests/peak(post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) none/tests/mremap(stderr) none/tests/mremap2 (stdout) none/tests/pth_cvsimple (stdout) none/tests/pth_detached (stdout) = == Difference between 24 hours ago and now == = *** old.short Sat Nov 3 03:16:55 2007 --- new.short Sat Nov 3 03:23:38 2007 *** *** 8,10 ! == 320 tests, 5 stderr failures, 4 stdout failures, 8 post failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ! == 320 tests, 4 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) *** *** 13,27 memcheck/tests/xml1 (stderr) - massif/tests/basic (post) - massif/tests/custom_alloc(post) - massif/tests/deep-D (post) - massif/tests/ignoring(post) - massif/tests/new-cpp (post) - massif/tests/overloaded-new (post) - massif/tests/peak(post) - massif/tests/peak2 (stderr) - massif/tests/peak2 (post) none/tests/mremap(stderr) none/tests/mremap2 (stdout) - none/tests/pth_cvsimple (stdout) - none/tests/pth_detached (stdout) --- 13,16 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
