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
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
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
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]. For example, when
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
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
Lasse Collin wrote:
> About sanitizers: They can be annoying with SIMD code. If a function is
> passed an unaligned buffer, it would be fine to round the address down
> to an aligned value, do an aligned read, and ignore the out-of-bounds
> bytes. One can do it in assembly because sanitizers don't
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 and non-descriptive of what the
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)
>
> or, in case I use libtool,
>
> LO
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 logic in freea.
>
> It would
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 uninitialized indicator wo
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)".
>
> Valgrind is not smart enough to underst
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 valgrind, I have problems t
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
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's test suite support Valgrind, but ther
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" errors
> to suppress on OS X too befor
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
>> such files?
>
> We alrea
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 the
respective
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 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
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.
---
ChangeLog
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
Ralf Wildenhues writes:
> * 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 m
* 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
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)/../
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
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 10 additional suppression
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
"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
46 matches
Mail list logo
