t of output to stderr and terminates with exit code 1.
Great. I have pushed this fix to gnulib.
/Simon
>From 9a0d285c9735ed65be2c63ba0db2c9d864bf7407 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Fri, 25 Nov 2011 00:20:17 +0100
Subject: [PATCH] valgrind-tests.m4: Avoid breakage
On 2011-09-07 13:22:09 +0200, Simon Josefsson wrote:
> Vincent, Bruno, if you can think of ways of making the situation better
> even for projects that use libtool wrappers of self-tests, then let's do
> that too -- I'm just mentioning that -no-install may be a solution.
Yes, I think this should b
Another solution is to put
AM_LDFLAGS = -no-install
in the Makefile.am of your self-test directory, so libtool will not
build wrappers for them.
I have not seen any negative effects of doing this, and it helps
significantly with issues like this (especially for running gdb).
Vincent, Bruno, if
Hi Vincent,
> valgrind-tests.texi says:
>
> However, this means that binaries invoked through scripts will not be
> invoked under valgrind, which could be solved by adding the following:
>
> @smallexample
> TESTS_ENVIRONMENT = VALGRIND='$(VALGRIND)'
> @end smallexample
>
> And then modify the s
Hi,
I've just done a test with the GNU MPC trunk, which is now based
on valgrind-tests.m4, and this is not compatible with libtool,
because it generates wrapper scripts.
valgrind-tests.texi says:
However, this means that binaries invoked through scripts will not be
invoked under valgrind,
Hello,
I made some enhancements to the valgrind-tests.m4 file which I find
quite handy and wanted to put tem into discussion.
The main changes are:
Memory leaks can be treated as errors
(--enable-valgrind-memleaks-are-errors)
Possibility for overriding the default arguments for valgrind via
Hi Ben,
* Ben Pfaff wrote on Thu, May 20, 2010 at 09:11:58PM CEST:
> Ralf Wildenhues writes:
>
> > That's quite bad. Maybe libtool should have a way to use valgrind only
> > on the "interesting" executable, not the rest of any wrappers, or the
> > libtool script, for efficiency reasons.
>
> To
Ralf Wildenhues writes:
> That's quite bad. Maybe libtool should have a way to use valgrind only
> on the "interesting" executable, not the rest of any wrappers, or the
> libtool script, for efficiency reasons.
To run valgrind on a program that might use libtool, I just use
libtool --mo
[ adding bug-libtool ]
* Bruno Haible wrote on Wed, May 19, 2010 at 11:12:08AM CEST:
> Simon Josefsson wrote:
> > my patch invokes valgrind with -q so that it does not
> > output anything, unless there are errors, of course
>
> Oh, I see. Indeed.
>
> But it spends a lot of time in "make check",
Ralf Wildenhues writes:
> Hi Simon,
>
> I like this patch, with one small nit:
>
> * Simon Josefsson wrote on Wed, May 19, 2010 at 08:41:29AM CEST:
>> +This will run all self-checks under valgrind. This can be wasteful if
>> +you have many shell scripts or other non-binaries. Using the Automake
ind, for self-tests.
Files:
m4/valgrind-tests.m4
+configure.ac:
+gl_VALGRIND_TESTS
+
License:
unlimited
--
1.7.1
Bruno Haible writes:
> The approach I use in GNU gettext is similar: Makefile.am has this:
>
> # For debugging memory leaks and memory allocation bugs.
> # You should build with --disable-shared when using valgrind.
> CHECKER =
> #CHECKER = valgrind --tool=memcheck
> --suppressions=$(srcdir)/../
Hi Simon,
I like this patch, with one small nit:
* Simon Josefsson wrote on Wed, May 19, 2010 at 08:41:29AM CEST:
> +This will run all self-checks under valgrind. This can be wasteful if
> +you have many shell scripts or other non-binaries. Using the Automake
> +parallel-tests feature, this can
Simon Josefsson wrote:
> my patch invokes valgrind with -q so that it does not
> output anything, unless there are errors, of course
Oh, I see. Indeed.
But it spends a lot of time in "make check", and does not exploit the full
information that valgrind could provide. For a test, I ran "make check
about this patch?
/Simon
>From 79e078df5d62ddd13aa173d1f62c22010f1b3c07 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Wed, 19 May 2010 08:41:10 +0200
Subject: [PATCH] valgrind-tests: New module.
---
ChangeLog |8
doc/gnulib.texi |3 +++
doc/valgrind
* Simon Josefsson wrote on Tue, May 18, 2010 at 09:36:44AM CEST:
> Ralf Wildenhues writes:
> > Well, one could prepend LOG_COMPILER (the default variable that doesn't
> > go with any specified extension) or have the developer specify some
> > other extension. Your macro could just set some variabl
MSGFMT="$(CHECKER) msgfmt" \
> MSGGREP="$(CHECKER) msggrep" \
> MSGINIT="$(CHECKER) msginit" \
> MSGMERGE="$(CHECKER) msgmerge" \
> MSGUNFMT="$(CHECKER) msgunfmt"
Bruno Haible writes:
> Ralf Wildenhues wrote:
>> > However, in general, tests might be executable programs, or
>> > they might be shell or other scripts. In the latter cases, putting
>> > valgrind in TESTS_ENVIRONMENT would be at least a waste (you don't want
>> > to check bash or perl).
>
> Not
Ralf Wildenhues wrote:
> > However, in general, tests might be executable programs, or
> > they might be shell or other scripts. In the latter cases, putting
> > valgrind in TESTS_ENVIRONMENT would be at least a waste (you don't want
> > to check bash or perl).
Not only it's a waste. It also prod
Ben Pfaff wrote:
> * In GNU PSPP, which mostly uses the built-in Automake
> test framework, the invocations of the test programs
> are all through shell scripts. Each invocation of a
> test program is preceded by $SUPERVISOR,
> e.g. "$SUPERVISOR pspp
Ralf Wildenhues writes:
>> > With Automake 1.11's parallel-tests option, you have the possibility
>> > to specify per-extension "compilers" for tests.
>> >
>> > Example:
>> > # .sh and .pl files are processed to .log files.
>> > TEST_EXTENSIONS = .sh .pl
>> > SH_LOG_COMPILER = bash -vx
>> >
Ben Pfaff writes:
> Simon Josefsson writes:
>
>> Ben Pfaff writes:
>>
>>> Simon Josefsson writes:
>>>
I'm running self-tests under valgrind in several projects, and it seems
like a general useful thing, so how about putting the macro for this in
gnulib?
>>>
>>> It looks like thi
Simon Josefsson writes:
> Ben Pfaff writes:
>
>> Simon Josefsson writes:
>>
>>> I'm running self-tests under valgrind in several projects, and it seems
>>> like a general useful thing, so how about putting the macro for this in
>>> gnulib?
>>
>> It looks like this implementation requires rerunn
* Simon Josefsson wrote on Mon, May 17, 2010 at 08:34:49PM CEST:
> Ralf Wildenhues writes:
> > * Simon Josefsson wrote on Mon, May 17, 2010 at 12:15:51PM CEST:
> >> I'm running self-tests under valgrind in several projects, and it seems
> >> like a general useful thing, so how about putting the mac
Ralf Wildenhues writes:
> Hi Simon,
>
> * Simon Josefsson wrote on Mon, May 17, 2010 at 12:15:51PM CEST:
>> I'm running self-tests under valgrind in several projects, and it seems
>> like a general useful thing, so how about putting the macro for this in
>> gnulib?
>
> Nice idea. However, in gen
Ben Pfaff writes:
> Simon Josefsson writes:
>
>> I'm running self-tests under valgrind in several projects, and it seems
>> like a general useful thing, so how about putting the macro for this in
>> gnulib?
>
> It looks like this implementation requires rerunning "configure"
> to run tests under
Hi Simon,
* Simon Josefsson wrote on Mon, May 17, 2010 at 12:15:51PM CEST:
> I'm running self-tests under valgrind in several projects, and it seems
> like a general useful thing, so how about putting the macro for this in
> gnulib?
Nice idea. However, in general, tests might be executable progr
Simon Josefsson writes:
> I'm running self-tests under valgrind in several projects, and it seems
> like a general useful thing, so how about putting the macro for this in
> gnulib?
It looks like this implementation requires rerunning "configure"
to run tests under valgrind. If that's right, it
03 +0200
Subject: [PATCH] valgrind-tests: New module.
---
ChangeLog |8
doc/gnulib.texi |3 +++
doc/valgrind-tests.texi | 16 ++++
m4/valgrind-tests.m4| 34 ++
modules/valgrind-tests | 11 +++
5 files
29 matches
Mail list logo
