Re: valgrind vs. sanitizers

On 2025-01-18 Paul Eggert wrote: > On 2025-01-18 11:45, Lasse Collin wrote: > > On 2025-01-18 Paul Eggert wrote: > >> Does the unaligned read trick work even with CheriBSD's memory-safe > >> model? That is an edge case that might need an ifdef or something. > >> > > > > I'm not familiar with C

Re: valgrind vs. sanitizers

On 2025-01-18 11:45, Lasse Collin wrote: On 2025-01-18 Paul Eggert wrote: Does the unaligned read trick work even with CheriBSD's memory-safe model? That is an edge case that might need an ifdef or something. I'm not familiar with CheriBSD but the trick never crosses a cache line boundary (or

Re: valgrind vs. sanitizers

On 2025-01-18 Paul Eggert wrote: > Does the unaligned read trick work even with CheriBSD's memory-safe > model? That is an edge case that might need an ifdef or something. I'm not familiar with CheriBSD but the trick never crosses a cache line boundary (or page boundary). So the memory-safe model

Re: valgrind vs. sanitizers

On 2025-01-18 Bruno Haible wrote: > Valgrind was a tool without replacement, for many years, when > sanitizers did not exist. Nowadays, however, I generally prefer > testing with sanitizers than with valgrind because there are some > bugs that ASAN finds and valgrind doesn't [1].

Re: valgrind vs. sanitizers

Paul Eggert wrote: > Does the unaligned read trick work even with CheriBSD's memory-safe > model? That is an edge case that might need an ifdef or something. Good question... > The aligned read trick reminds me a bit of the "adding 0 to a null > pointer gives you a null pointer" trick. That als

Re: valgrind vs. sanitizers

On 2025-01-18 07:48, Bruno Haible via Gnulib discussion list wrote: Regarding your trick to do an aligned read on (addr & -alignment) instead of an unaligned read on (addr): I find it good that ASAN catches this, because this trick amounts to exploiting a coincidental property of current hardware

Re: valgrind vs. sanitizers

tizers don't see it. In > contrast to sanitizers, Valgrind is happy if the extra bytes are thrown > away. Valgrind was a tool without replacement, for many years, when sanitizers did not exist. Nowadays, however, I generally prefer testing with sanitizers than with valgrind because t

Re: [PATCH] valgrind-tests: Better option handling.

Hi Simon, > > Assuming I am a GNU package maintainer and I read this paragraph. How do > > I know whether my package uses the "old serial test harness"? Can I > > determine this by looking at configure.ac? Or at the main Makefile.am? > > I suspect almost everyone is using the parallel test harnes

Re: [PATCH] valgrind-tests: Better option handling.

ngs to make it actual work too. Another read through the manual section would be welcome to make sure it is now correct and complete. Review of the recent changes to valgrind-tests.m4 is also appreciated - I didn't want to break backwards compatibility for the VALGRIND variable so it became a bit

Re: [PATCH] valgrind-tests: Better option handling.

Hi Simon, > +Replace @code{LOG_COMPILER} with @code{TESTS_ENVIRONMENT} if you are > +using the old serial test harness. Assuming I am a GNU package maintainer and I read this paragraph. How do I know whether my package uses the "old serial test harness"? Can I determine this by looking at configu

Re: [PATCH] valgrind-tests: Better option handling.

Further testing quickly found a small bug, pushed. /Simon From 784fdea59920d69998b59ab326c11a8a2a93ef88 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Fri, 14 May 2021 15:03:25 +0200 Subject: [PATCH] valgrind-tests: Fix LOG_VALGRIND when valgrind is missing. * m4/valgrind-tests.m4: Clear

[PATCH] valgrind-tests: Better option handling.

Hi. I have pushed the attached patch. It should be completely backwards compatible, or there is a bug, so please test this. It adds two new variables to allow both developers and users to influence the valgrind options used. You may want to re-read the manual, I updated it to assume people use

Re: valgrind-tests

Simon Josefsson wrote: > Btw, I just realized the module is confusingly named, since > modules/*-tests is used in gnulib to designate gnulib module self-tests. > Nothing appears to break, and I can't think of a better name right now > ('valgrind' is a bit too general

Re: GNU SASL 1.9.2 and valgrind

Bruno Haible writes: >> Right. It would be nice if gnulib's valgrind m4 test was a bit >> smarter, maybe it should try to build a small program printing >> something to stdout and see if valgrind is able to run it and that it >> prints the magic string to stdout.

Re: GNU SASL 1.9.2 and valgrind

l > > tests: > > Right. It would be nice if gnulib's valgrind m4 test was a bit > smarter, maybe it should try to build a small program printing > something to stdout and see if valgrind is able to run it and that it > prints the magic string to stdout. If that doesn&#

valgrind-tests: Really enable the valgrind options test

The "checking for valgrind options for tests..." tests in module valgrind-tests does not work: It says "yes" even when these options don't work. Due to a reference to undefined variable gl_valgrind_opts. 2021-01-02 Bruno Haible valgrind-tests: Really enable

Re: valgrind-tests and suppression files

On Sat, May 23, 2020 at 5:40 PM Marc Nieper-Wißkirchen wrote: > > Is there any built-in support in the valgrind-tests module for > suppression files? For example, if I want to run my tests under > valgrind (if available), I write > > LOG_COMPILER = $(VALGRIND) > > o

valgrind-tests and suppression files

Is there any built-in support in the valgrind-tests module for suppression files? For example, if I want to run my tests under valgrind (if available), I write LOG_COMPILER = $(VALGRIND) or, in case I use libtool, LOG_COMPILER = $(LIBTOOL) --mode=execute $(VALGRIND) But how to add valgrind

tests: prepare for using valgrind

ingle unit test with valgrind. The way to do so is documented in https://www.gnu.org/software/gnulib/manual/html_node/Valgrind-and-shell-scripts.html. Namely, one needs to add an environment variable reference before every invocation of a program to be tested. I'm using the variable named

add script for running tests under valgrind

This patch does two things: * It adds a script for running tests under valgrind, that I developed for GNU libunistring and want to use elsewhere as well, to gnulib. * It revamps the documentation section "Running self-tests under valgrind" to mention alternative approach

Re: Valgrind is complaining unitialized values in freea (malloca.c:135)

Hi, Marc Nieper-Wißkirchen wrote: > In freea in malloca.c, a possibly uninitialized indicator word is used for > a comparison so that Valgrind reports: "Conditional jump or move depends on > uninitialised value(s)". > > Valgrind is not smart enough to understand the logi

Re: Valgrind is complaining unitialized values in freea (malloca.c:135)

I just noticed the file lib/malloca.valgrind, which can be used with the Valgrind option suppressions. Marc Am 22.08.2017 5:52 nachm. schrieb "Tim Rühsen" : > On Dienstag, 22. August 2017 06:11:41 CEST Marc Nieper-Wißkirchen wrote: > > In freea in malloca.c, a possibly unin

Re: Valgrind is complaining unitialized values in freea (malloca.c:135)

On Dienstag, 22. August 2017 06:11:41 CEST Marc Nieper-Wißkirchen wrote: > In freea in malloca.c, a possibly uninitialized indicator word is used for > a comparison so that Valgrind reports: "Conditional jump or move depends on > uninitialised value(s)". > > Valgri

Valgrind is complaining unitialized values in freea (malloca.c:135)

In freea in malloca.c, a possibly uninitialized indicator word is used for a comparison so that Valgrind reports: "Conditional jump or move depends on uninitialised value(s)". Valgrind is not smart enough to understand the logic in freea. It would be nice if the warning could be silenc

Re: Problem with valgrind-tests: relies on bash not causing error

On 5 August 2017 at 19:46, Paul Eggert wrote: > Thanks, I installed the attached somewhat-more-fancier patch; does it work > for you? > ​That works fine; thanks very much. -- https://rrt.sc3d.org

Re: Problem with valgrind-tests: relies on bash not causing error

Thanks, I installed the attached somewhat-more-fancier patch; does it work for you? >From 59c181fa400ead71e9a28e3db9abc107f8fc9ea3 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 5 Aug 2017 11:45:10 -0700 Subject: [PATCH] valgrind-tests: use ls, and cache * m4/valgrind-tests.m4: Test

Re: Problem with valgrind-tests: relies on bash not causing error

On 12 April 2017 at 13:36, Reuben Thomas wrote: > The test for whether to use valgrind runs: > > /bin/bash -c 'exit 0' > > This looks pretty harmless; unfortunately, bash itself causes problems: > > $ valgrind -q --error-exitcode=1 --leak-check=full /bin/bash -c &#

Re: valgrind

On Mittwoch, 17. Mai 2017 19:09:05 CEST Bruno Haible wrote: > Hi Tim, > > > How do I enable valgrind testing ? > > There is this doc [1] and this recent mail thread [2]. Ok, there seems to a misunderstanding. While I have no problems to setup/run most projects to use valgrin

Re: valgrind

Hi Tim, > How do I enable valgrind testing ? There is this doc [1] and this recent mail thread [2]. Bruno [1] https://www.gnu.org/software/gnulib/manual/html_node/Running-self_002dtests-under-valgrind.html [2] https://lists.gnu.org/archive/html/bug-gnulib/2017-04/msg00041.html

Re: Problem with valgrind-tests: relies on bash not causing error

On 04/14/2017 10:56 PM, Marc Nieper-Wißkirchen wrote: > While your proposed solution would work for anyone who is aware of this > problem, it won't work for an unaware user who would simply run ./configure, > wondering why valgrind isn't detected. As it seems > rather i

Re: Problem with valgrind-tests: relies on bash not causing error

Hi Bruno, Hi Reuben, >/The test for whether to use valgrind runs:/ >// >//bin/bash -c 'exit 0'/ >// >/This looks pretty harmless; unfortunately, bash itself causes problems:/ I'd suggest that you change m4/valgrind-tests.m4 to use the AC

Re: Problem with valgrind-tests: relies on bash not causing error

On 12 April 2017 at 15:23, Bruno Haible wrote: > Hi Reuben, > > > This is a separate issue, though: the real problem here is that a way is > > needed to run libtool wrappers with libtool > > In GNU gettext, I never succeeded in making valgrind work with the libtool >

Re: Problem with valgrind-tests: relies on bash not causing error

Hi Reuben, > This is a separate issue, though: the real problem here is that a way is > needed to run libtool wrappers with libtool In GNU gettext, I never succeeded in making valgrind work with the libtool wrappers; instead I noted # You should build with --disable-shared when using va

Re: Problem with valgrind-tests: relies on bash not causing error

Hi Reuben, > The test for whether to use valgrind runs: > > /bin/bash -c 'exit 0' > > This looks pretty harmless; unfortunately, bash itself causes problems: I'd suggest that you change m4/valgrind-tests.m4 to use the AC_CACHE_CHECK macro instead of "lone

Re: Problem with valgrind-tests: relies on bash not causing error

On 12 April 2017 at 13:47, Reuben Thomas wrote: > > > I guess one further option is to fix the bug in bash, and then call > valgrind with --trace-children=yes. Maybe that would be cleanest and > simplest (albeit we'll need a workaround until fixed bash is widely > availa

Re: Problem with valgrind-tests: relies on bash not causing error

​Having applied the workaround of using "ls" in the configure test, my tests still don't run because the LOG_COMPILER trick suggested in the gnulib manual doesn't take account of libtool wrappers. Net result: valgrind is being called on bash (as it runs the test binary's

Problem with valgrind-tests: relies on bash not causing error

The test for whether to use valgrind runs: /bin/bash -c 'exit 0' This looks pretty harmless; unfortunately, bash itself causes problems: $ valgrind -q --error-exitcode=1 --leak-check=full /bin/bash -c 'exit 0' ==32197== Invalid free() / delete / delete[] / realloc() ==321

Re: gnulib's malloca use under valgrind

Hi Nikos, > When we enabled running tests under valgrind in libidn2 [0] we found > out this issue, which involves the unistring/iconv part of the gnulib > code: > > ==3644== Conditional jump or move depends on uninitialised value(s) > ==3644==at 0x4E3EBCC: freea (mallo

gnulib's malloca use under valgrind

Hi, When we enabled running tests under valgrind in libidn2 [0] we found out this issue, which involves the unistring/iconv part of the gnulib code: ==3644== Conditional jump or move depends on uninitialised value(s) ==3644==at 0x4E3EBCC: freea (malloca.c:134) ==3644==by 0x4E40C1D

Re: [PATCH] flexmember: port better to GCC + valgrind

On Wed, Sep 7, 2016 at 2:03 AM, Paul Eggert wrote: > With a char[] flexible array member in a struct with nontrivial > alignment, GCC-generated code can access past the end of the > array, because GCC assumes there are padding bytes to get the > struct aligned. So the common idiom of malloc (offs

[PATCH] flexmember: port better to GCC + valgrind

/ChangeLog @@ -1,3 +1,37 @@ +2016-09-07 Paul Eggert + + flexmember: port better to GCC + valgrind + With a char[] flexible array member in a struct with nontrivial + alignment, GCC-generated code can access past the end of the + array, because GCC assumes there are padding bytes to

Re: [PATCH] valgrind-tests: fixed misleading help message

On 05/30/2014 01:47 PM, Kieran Colford wrote: > The help message generated by a configure script using this module > implied that valgrind was disabled by default, which it wasn't. > Left the auto enablement in and patched the help message like: > s/enable/disable/ &

[PATCH] valgrind-tests: fixed misleading help message

The help message generated by a configure script using this module implied that valgrind was disabled by default, which it wasn't. Left the auto enablement in and patched the help message like: s/enable/disable/ --- ChangeLog|8 m4/valgrind-tests.m4 |4 ++-- 2

Re: [PATCH] valgrind-tests: fixed misleading help message.

On 14-05-30 06:59 AM, Pádraig Brady wrote: > On 05/28/2014 04:53 PM, Kieran Colford wrote: >> The help message generated by a configure script using this module >> implied that valgrind was disabled by default, which it wasn't. >> Patched so that valgrind is in fact d

Re: [PATCH] valgrind-tests: fixed misleading help message.

On 05/28/2014 04:53 PM, Kieran Colford wrote: > The help message generated by a configure script using this module > implied that valgrind was disabled by default, which it wasn't. > Patched so that valgrind is in fact disabled in accordance with the > documentation. Note doc/va

[PATCH] valgrind-tests: fixed misleading help message.

The help message generated by a configure script using this module implied that valgrind was disabled by default, which it wasn't. Patched so that valgrind is in fact disabled in accordance with the documentation. --- ChangeLog|8 m4/valgrind-tests.m4 |4 ++-- 2

[PATCH] valgrind-tests: fixed misleading help message.

The help message generated by a configure script using this module implied that valgrind was disabled by default, which it wasn't. Patched so that valgrind is in fact disabled in accordance with the documentation. --- ChangeLog|7 +++ m4/valgrind-tests.m4 |4 ++-- 2

Re: Valgrind suppression files

Le 18 juil. 2012 à 10:50, Bruno Haible a écrit : > Akim Demaille wrote: >> In the past I had been working on a package where there were >> issues in glibc that were not recorded in a shipped >> suppression file. It was the same thing for OS X. >> >> Bison&#

Re: Valgrind suppression files

Akim Demaille wrote: > In the past I had been working on a package where there were > issues in glibc that were not recorded in a shipped > suppression file. It was the same thing for OS X. > > Bison's test suite support Valgrind, but there are many "native" er

Re: Valgrind suppression files

Le 17 juil. 2012 à 18:42, Bruno Haible a écrit : > Hi Akim, Hi Bruno! >> There are some architectures on which the Valgrind suppression >> files can be time consuming to maintain. How about sharing these >> guys in gnulib? Or, do you know some public repository of &

Re: Valgrind suppression files

Hi Akim, > There are some architectures on which the Valgrind suppression > files can be time consuming to maintain. How about sharing these > guys in gnulib? Or, do you know some public repository of > such files? We already have valgrind suppression files in gnulib, as part of th

Valgrind suppression files

Hi friends, There are some architectures on which the Valgrind suppression files can be time consuming to maintain. How about sharing these guys in gnulib? Or, do you know some public repository of such files?

valgrind-tests.m4 improvement (was: Re: libtasn1 2.11 pre-release)

Bruno Haible writes: > Hi Simon, > >> > * Linux/x86_64 >> > >> > 8 of 8 tests failed >> > >> > The reason is that I have valgrind 3.5.0 installed, and "make >> > check" apparently >> > runs valgrind on many 'ba

Re: valgrind-tests.m4 is not compatible with libtool

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

Re: valgrind-tests.m4 is not compatible with libtool

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

Re: valgrind-tests.m4 is not compatible with libtool

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 sma

valgrind-tests.m4 is not compatible with libtool

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,

Re: Support for options in valgrind-tests

On 17 March 2011 06:27, Ralf Wildenhues wrote: > I suggest you guys check out the parallel-tests driver from recent > Automake.  It provides makefile variables for specifying a command > to run specific tests, plus options to that.  That can be used for > valgrind. It would certainl

Re: Support for options in valgrind-tests

I suggest you guys check out the parallel-tests driver from recent Automake. It provides makefile variables for specifying a command to run specific tests, plus options to that. That can be used for valgrind. Quoting the documentation: For tests that match an extension `.EXT' list

Re: Support for options in valgrind-tests

On 16 March 2011 23:42, Bernd Becker wrote: > Am 16.03.2011 22:52, schrieb Reuben Thomas: >> Sounds like what's needed is a pair of variables that works like >> CPPFLAGS/AM_CPPFLAGS. >> > how about an approach passing a variable into make like > test_a_VALGRIND_OPTIONS=foo make check > then you sa

Re: Support for options in valgrind-tests

Am 16.03.2011 22:52, schrieb Reuben Thomas: > On 16 March 2011 21:22, Bernd Becker wrote: >> Hi Thomas, >> >> Am 12.03.2011 18:41, schrieb Reuben Thomas: >>> Another day, another nice surprise from gnulib: it supports valgrind, >>> so I can remove my own co

Re: Support for options in valgrind-tests

On 16 March 2011 21:22, Bernd Becker wrote: > Hi Thomas, > > Am 12.03.2011 18:41, schrieb Reuben Thomas: >> Another day, another nice surprise from gnulib: it supports valgrind, >> so I can remove my own code for that...only, no I can't, because I add >> options

Re: Support for options in valgrind-tests

Hi Thomas, Am 12.03.2011 18:41, schrieb Reuben Thomas: > Another day, another nice surprise from gnulib: it supports valgrind, > so I can remove my own code for that...only, no I can't, because I add > options (I add --error-exitcode=1 --leak-check=full). > > So, two alt

Support for options in valgrind-tests

Another day, another nice surprise from gnulib: it supports valgrind, so I can remove my own code for that...only, no I can't, because I add options (I add --error-exitcode=1 --leak-check=full). So, two alternative suggestions: 1. Agree that these options are must-haves (rationale: one&#

enhancements valgrind-tests.m4

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

Re: valgrind-tests.m4

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

Re: valgrind-tests.m4

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

Re: valgrind-tests.m4

[ 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

Re: valgrind-tests.m4

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 oth

Re: valgrind-tests.m4

I pushed a small followup-patch to make things work. /Simon >From 5c9bee128e78e2513fef8955c4c0cd27fcff4c54 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Thu, 20 May 2010 08:37:18 +0200 Subject: [PATCH] modules/valgrind-tests (configure.ac): Invoke gl_VALGRIND_TESTS. --- Change

Re: valgrind-tests.m4

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 > --

Re: valgrind-tests.m4

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 feat

libunistring: add a valgrind suppressions file

This patch adds a file that can be used with valgrind's --suppressions option. 2010-05-19 Bruno Haible Avoid valgrind error reports from libunistring. * lib/libunistring.valgrind: New file, based on lib/malloca.valgrind. * modules/libunistring (Files): A

Re: valgrind-tests.m4

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 t

Re: valgrind-tests.m4

xibility, but of course require >> > a bit more work for the package author. >> >> How would this solve the problem of running valgrind on scripts? I'm >> not familiar with the new parallel-tests stuff, but isn't LOG_COMPILER >> applied for all extensions?

Re: valgrind-tests.m4

the package author. > > How would this solve the problem of running valgrind on scripts? I'm > not familiar with the new parallel-tests stuff, but isn't LOG_COMPILER > applied for all extensions? LOG_COMPILER is used for all tests which do not match any of the extensions gi

Re: valgrind-tests.m4

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 > --

Re: valgrind-tests.m4

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

Re: valgrind-tests.m4

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). N

Re: valgrind-tests.m4

g. "$SUPERVISOR pspp ...". Then running "make check" > runs without valgrind; running "make check > SUPERVISOR='libtool --mode=execute valgrind'" runs with > valgrind; and so on. (Sometimes 'libtool > --m

Re: valgrind-tests.m4

t; > TEST_EXTENSIONS = .sh .pl >> > SH_LOG_COMPILER = bash -vx >> > PL_LOG_COMPILER = perl -w -m strict >> > TESTS = foo.sh bar.pl baz.sh >> >> I don't see how to use this for running valgrind only on compiled .c >> files though. Or a

Re: valgrind-tests.m4

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

Re: valgrind-tests.m4

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

Re: valgrind-tests.m4

* 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

Re: valgrind-tests.m4

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 >> gnu

Re: valgrind-tests.m4

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 r

Re: valgrind-tests.m4

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

Re: valgrind-tests.m4

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 va

valgrind-tests.m4

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? /Simon >From 1ec8622b3a4efed0ebaaa4eb19d440fab1708b4e Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Mon, 17 May 2010 12:15:

Re: memchr and valgrind

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 6/15/2009 11:42 AM: > With the recent clarification on memchr behavior, it is conceivable that we > could trip false positives under valgrind when using memchr to find the > location of a known byte with an over

memchr and valgrind

With the recent clarification on memchr behavior, it is conceivable that we could trip false positives under valgrind when using memchr to find the location of a known byte with an overestimated length (most frequently when searching for a NUL). Any objections to applying this patch? From

Re: valgrind

Eric Blake wrote: > But 'man valgrind' states: > --suppressions= [default: $PREFIX/lib/valgrind/default.supp] > Specifies an extra file from which to read > descriptions of errors to suppress. You may spec- > ify up to

Re: Valgrind and Bison memory leaks

On Wed, 8 Nov 2006, Paul Eggert wrote: > "Joel E. Denny" <[EMAIL PROTECTED]> writes: > > > Most importantly, the end of the patch includes a small change to > > lib/quotearg.*, which I see are part of gnulib. I'll need some guidance > > on whether that change makes sense for gnulib in general

Re: Valgrind and Bison memory leaks

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > Most importantly, the end of the patch includes a small change to > lib/quotearg.*, which I see are part of gnulib. I'll need some guidance > on whether that change makes sense for gnulib in general and on what to do > with it. OK, on further thou