valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] mremap and external address

[Tom H. <to...@co...>]

On 06/11/2018 17:02, Rafael Antognolli wrote:

> My (limited) understanding is that valgrind's mremap doesn't let me 
> remap an address that was allocated by the ioctl, since valgrind doesn't 
> "own" that memory. Is there some way around this, or this is never 
> supposed to work?

I don't see any reason why it shouldn't IF the ioctl wrapper is
correctly written to update valgrind's internal state and record
the mapping that it creates.

If the wrapper doesn't do that then you probably have bigger
problems than whether you can remap it because it will mean
valgrind's state is out of sync with the kernel.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] mremap and external address

[Rafael A. <ant...@gm...>]

Hi,

I currently have some code that tries to use mremap to put a mapping done
by the kernel into a different address, which I previously "reserved" with
an anonymous mmap. Something like this:

void *map;
map = mmap(NULL, BLOCK_POOL_MEMFD_SIZE, PROT_READ | PROT_WRITE,
           MAP_SHARED | MAP_ANONYMOUS, -1, 0);
/* check for MAP_FAILED */

/* some code to setup BO (buffer object) */
gem_handle = anv_gem_create(pool->device, size);
void *newmap;
newmap = anv_gem_mmap(pool->device, gem_handle, 0, size, 0);

/* this fails with MAP_FAILED*/
newmap = mremap(newmap, size, size, MREMAP_MAYMOVE | MREMAP_FIXED,
                     map + pool->size);



My (limited) understanding is that valgrind's mremap doesn't let me remap
an address that was allocated by the ioctl, since valgrind doesn't "own"
that memory. Is there some way around this, or this is never supposed to
work?

I also tried using VALGRIND_MAKE_MEM_DEFINED on the "newmap", but that
didn't make any difference.


Thank you,
Rafael

PS: Sorry for the formatting, sending this from gmail :-/

Re: [Valgrind-users] Optimization flags to speed unit tests running under valgrind

[Julian S. <js...@ac...>]

On 05/11/18 01:49, John Carter wrote:

> For example, what optimization flags (for compiling the unit tests) have
> been found helpful? 

What flags are you using at the moment, for your unit tests?

I have tended to use -Og -g as a reasonable tradeoff between debuggability
and performance (which is its intended aim anyway).  With gcc this works
quite well.  I've had more mixed performance results with clang using -g -Og.

Probably the most important thing is to avoid building your test cases with
-O0 (that is, no optimisation at all).  That causes gcc, at least, to produce
very poor code, involving many unnecessary memory references, which makes
Memcheck run very slowly.  Even -Og, which is the least level of optimisation
one can ask for above "none", drastically reduces memory traffic and
thereby makes Memcheck run significantly faster.

J

Re: [Valgrind-users] Optimization flags to speed unit tests running under valgrind

[John C. <joh...@ta...>]

Thanks for the replies...

Tweaking the optimization settings did very little for the running time.

However a huge difference (factor of 2) comes from taking out
--show-reachable=yes --track-origins=yes except they are very very
useful... so I sort of don't want to.


On Tue, Nov 6, 2018 at 9:43 AM Philippe Waroquiers <
phi...@sk...> wrote:

> On Sun, 2018-11-04 at 20:36 -0800, John Reiser wrote:
> > > What techniques can we employ to speed things up (whilst retaining
> most of the value)?
>
> > The memcheck option --expensive-definedness-checks= already defaults to
> 'no'.
> Note that it defaults to 'auto' in 3.14.
>
> > Specifying --redzone-size=8 might save 16 bytes of memory for each
> allocation,
> > which helps if there are many small allocations.  But default
> --alignment=16
> > is required for common SSE2 instructions [used by other glibc routines
> on the blocks,
> > etc.], and the redzone is not the only per-block overhead (see
> --keep-stacktraces=
> > and --num-callers=), so experimentation may be required.
> >
> > If all you care about is memory leaks, then experiment with
> --undef-value-errors=no
> > and even non-valgrind tools [such as mtrace (malloc trace)] that are
> specialized
> > for detecting leaks.
>
> You might look at the FOSDEM presentation
>  'Tuning Valgrind for your Workload
>      Hints, tricks and tips to effectively use Valgrind on small or big
>
>      applications'
> https://archive.fosdem.org/2015/schedule/event/valgrind_tuning/
>
> for other suggestions.
>
> Philippe
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand

-- 
This Communication is Confidential. We only send and receive email on the

basis of the terms set out at www.taitradio.com/email_disclaimer 
<http://www.taitradio.com/email_disclaimer>

Re: [Valgrind-users] Missing debug symbols

[Philippe W. <phi...@sk...>]

On Mon, 2018-11-05 at 15:30 -0500, Shahbaz Youssefi wrote:
> Looks like I was slightly too quick to ask this question. The issue
> seems to be coming from the way LLD produces debugging information,
> and adding --no-resegment to LLD fixes the issue:
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=830706

 Note that the above references valgrind bug 384727,
duplicate of 395682, which is fixed in valgrind 3.14.

So, if you upgrade to latest valgrind release, it should
work without --no-resegment.

Philippe

Re: [Valgrind-users] Optimization flags to speed unit tests running under valgrind

[Philippe W. <phi...@sk...>]

On Sun, 2018-11-04 at 20:36 -0800, John Reiser wrote:
> > What techniques can we employ to speed things up (whilst retaining most of the value)?

> The memcheck option --expensive-definedness-checks= already defaults to 'no'.
Note that it defaults to 'auto' in 3.14.

> Specifying --redzone-size=8 might save 16 bytes of memory for each allocation,
> which helps if there are many small allocations.  But default --alignment=16
> is required for common SSE2 instructions [used by other glibc routines on the blocks,
> etc.], and the redzone is not the only per-block overhead (see --keep-stacktraces=
> and --num-callers=), so experimentation may be required.
> 
> If all you care about is memory leaks, then experiment with --undef-value-errors=no
> and even non-valgrind tools [such as mtrace (malloc trace)] that are specialized
> for detecting leaks.

You might look at the FOSDEM presentation
 'Tuning Valgrind for your Workload
     Hints, tricks and tips to effectively use Valgrind on small or big     
     applications'
https://archive.fosdem.org/2015/schedule/event/valgrind_tuning/

for other suggestions.

Philippe

Re: [Valgrind-users] Missing debug symbols

[Shahbaz Y. <sh...@gm...>]

Looks like I was slightly too quick to ask this question. The issue
seems to be coming from the way LLD produces debugging information,
and adding --no-resegment to LLD fixes the issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=830706
On Mon, Nov 5, 2018 at 3:24 PM Shahbaz Youssefi <sh...@gm...> wrote:
>
> Hi,
>
> I'm in the following situation and need help understanding why
> valgrind doesn't show debug symbols. First of all, I'm on Linux 4.15
> x86_64, valgrind 3.13.0. I'm running valgrind on ANGLE
> (angleproject.org). Normally, this library provides a .so file that I
> believe gets dynamically loaded, but a few of the tests statically
> link against this library.
>
> Verification #1: I can verify that the executable I'm running is
> statically linked because ldd doesn't show a dependency to the
> library.
>
> I know the debug symbols are there. The code is built with -g2.
>
> Verification #2: Running gdb on the execution and breaking shows the
> symbols. `nm -l` shows the symbols and their paths as well.
>
> However, the stack traces I get from valgrind are of the following form:
>
> ==1199==    at 0x61F1F89: sched_setaffinity@@GLIBC_2.3.4
> (sched_setaffinity.c:35)
> ==1199==    by 0x3B3D7F: ??? (in /path/to/angle_perftests)
> ==1199==    by 0x326D02: ??? (in /path/to/angle_perftests)
> ==1199==    by 0x38F6FC: ??? (in /path/to/angle_perftests)
> ==1199==    by 0x39082F: ??? (in /path/to/angle_perftests)
> ==1199==    by 0x390EC6: ??? (in /path/to/angle_perftests)
> ==1199==    by 0x39CF86: ??? (in /path/to/angle_perftests)
> ==1199==    by 0x39CAAB: ??? (in /path/to/angle_perftests)
> ==1199==    by 0x37CB0D: ??? (in /path/to/angle_perftests)
> ==1199==    by 0x610FB96: (below main) (libc-start.c:310)
> ==1199==  Address 0x1ffefff9c8 is on thread 1's stack
>
> This doesn't match any of the possible outputs in question 4.2 of the
> faq (http://valgrind.org/docs/manual/faq.html)!
>
> If I run readelf -s, then I can see that many of the symbols are
> marked as HIDDEN under the Vis column (something for which I can't
> seem to find any documentation).
>
> Can anybody make sense of what's going on, or has any idea why
> valgrind is unable to give me debug symbols?
>
> Cheers,

[Valgrind-users] Missing debug symbols

[Shahbaz Y. <sh...@gm...>]

Hi,

I'm in the following situation and need help understanding why
valgrind doesn't show debug symbols. First of all, I'm on Linux 4.15
x86_64, valgrind 3.13.0. I'm running valgrind on ANGLE
(angleproject.org). Normally, this library provides a .so file that I
believe gets dynamically loaded, but a few of the tests statically
link against this library.

Verification #1: I can verify that the executable I'm running is
statically linked because ldd doesn't show a dependency to the
library.

I know the debug symbols are there. The code is built with -g2.

Verification #2: Running gdb on the execution and breaking shows the
symbols. `nm -l` shows the symbols and their paths as well.

However, the stack traces I get from valgrind are of the following form:

==1199==    at 0x61F1F89: sched_setaffinity@@GLIBC_2.3.4
(sched_setaffinity.c:35)
==1199==    by 0x3B3D7F: ??? (in /path/to/angle_perftests)
==1199==    by 0x326D02: ??? (in /path/to/angle_perftests)
==1199==    by 0x38F6FC: ??? (in /path/to/angle_perftests)
==1199==    by 0x39082F: ??? (in /path/to/angle_perftests)
==1199==    by 0x390EC6: ??? (in /path/to/angle_perftests)
==1199==    by 0x39CF86: ??? (in /path/to/angle_perftests)
==1199==    by 0x39CAAB: ??? (in /path/to/angle_perftests)
==1199==    by 0x37CB0D: ??? (in /path/to/angle_perftests)
==1199==    by 0x610FB96: (below main) (libc-start.c:310)
==1199==  Address 0x1ffefff9c8 is on thread 1's stack

This doesn't match any of the possible outputs in question 4.2 of the
faq (http://valgrind.org/docs/manual/faq.html)!

If I run readelf -s, then I can see that many of the symbols are
marked as HIDDEN under the Vis column (something for which I can't
seem to find any documentation).

Can anybody make sense of what's going on, or has any idea why
valgrind is unable to give me debug symbols?

Cheers,

Re: [Valgrind-users] Optimization flags to speed unit tests running under valgrind

[John R. <jr...@bi...>]

> What techniques can we employ to speed things up (whilst retaining most of the value)?

In general, memcheck runs faster when it emulates fewer instructions.  So compile with
-O2 to get smaller code size.  The flag -Os means "prefer small code size" but is
little used, so there just might be more compiler bugs.  Secondly, do whatever
it takes to *avoid* inlining string functions such as strlen etc.  You want memcheck
to replace the entire logical function call with a memcheck internal equivalent.
Unfortunately the gcc flags -fno-builtin* have documentation that is hard to understand.

The memcheck option --expensive-definedness-checks= already defaults to 'no'.
Specifying --redzone-size=8 might save 16 bytes of memory for each allocation,
which helps if there are many small allocations.  But default --alignment=16
is required for common SSE2 instructions [used by other glibc routines on the blocks,
etc.], and the redzone is not the only per-block overhead (see --keep-stacktraces=
and --num-callers=), so experimentation may be required.

If all you care about is memory leaks, then experiment with --undef-value-errors=no
and even non-valgrind tools [such as mtrace (malloc trace)] that are specialized
for detecting leaks.

[Valgrind-users] Optimization flags to speed unit tests running under valgrind

[John C. <joh...@ta...>]

We run our suite of unit tests under valgrind.... Something which is
immensely helpful.

However as suite grows and grows.... it is starting to take significant
time, even when spread across multiple cores.

What techniques can we employ to speed things up (whilst retaining most of
the value)?

For example, what optimization flags (for compiling the unit tests) have
been found helpful? (We want the sum of compilation and link and unit test
run time to be minimized)

Are there any valgrind flags that would speed things up?

Thanks!

-- 
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand

-- 
This Communication is Confidential. We only send and receive email on the

basis of the terms set out at www.taitradio.com/email_disclaimer 
<http://www.taitradio.com/email_disclaimer>

[Valgrind-users] Need Help On Build /Target/Host

[Padala D. <pad...@gm...>]

Hi

I am trying to cross compile the valgrind for arm. Need help me with the
options for build /target and host?

I am trying different options but unable to succeed in the build

My build machine is
uname -a
Linux in-mvlb24 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

Target system is
uname -a
Linux arm_hw 3.10.53.cge-rt50 #1 PREEMPT Tue Aug 1 14:39:13 IST 2017 armv7l
GNU/Linux

Thanks & Regards
Dileep Padala

Re: [Valgrind-users] Runtime error while running valgrind binary

[Padala D. <pad...@gm...>]

Hi John,

Thanks for clarifying the issue with monta-vista.
So i cannot proceed to use vlagrind on my target. I have two targets.

root@Infinera-Linux lib]# uname -a
Linux  xx-Linux 3.10.40.cge-rt38 #2 SMP Thu Nov 6 13:58:21 PST 2014 i686
GNU/Linux for which export
CC=/opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-gcc is
used


root@arm_hw:~# uname -a
Linux arm_hw 3.10.53.cge-rt50 #1 PREEMPT Tue Aug 1 14:39:13 IST 2017 armv7l
GNU/Linux for which export
CC=/opt/mv_7/arm/tools/arm-gnu/bin/arm-montavista-linux-gnueabi-gcc is used
.

These are the two environments my product runs. I am not sure if I can use
any other software development evirionment

Thanks & Regards
Dileep



On Wed, Oct 24, 2018 at 9:06 PM John Reiser <jr...@bi...> wrote:

> On 10/24/18, Padala Dileep wrote:
> > I see below information
> >
> which /opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++
> > x86_64-montavista-linux-gnu-g++ (MontaVista Linux G++ 4.7-140716013314)
> 4.7.0
> >
> > /opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++
> --print-file-name=libc.so
> >
> /opt/mv_7/install/x86_64/montavista/tools/x86_64-gnu/libexec/../x86_64-montavista-linux-gnu/sys-root/usr/lib/../lib64/libc.so
>
> > On Wed, Oct 24, 2018 at 8:00 PM Padala Dileep <pad...@gm...
> <mailto:pad...@gm...>> wrote:
> >
> >     Hi John,
> >     Thanks for your response.
> >     Which libc (glibc, uClibc, dietLibc, musl, ...) does this system
> have?
> >     How to check this one?
> >     Did you do anything to libc after installation, such as strip
> symbols? No
> >     (Or did the install process itself strip symbols?)   No
> >
> >     The libraries generally gets store in a directory /lib on the
> target, I have treid setting the VALGRIND_PATH to this library path
>
> Complain to MontaVista: they are unfriendly to valgrind, which means
> unfriendly
> to software developers who use MontaVista products. They have compiled
> ld-linux.so.2
> such that 'strlen' has been inlined using SSE* instructions.  That cannot
> possibly
> make any difference in the speed of ld-linux, but it is obnoxious to
> valgrind.
> MontaVista should compile ld-linux with -fno-builtin-strlen .
> Meanwhile you should use a software development environment that is
> friendly to valgrind.
>
> For esoteric technical details see:
> https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1247026/comments/12
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Runtime error while running valgrind binary

[John R. <jr...@bi...>]

On 10/24/18, Padala Dileep wrote:
> I see below information
> which /opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++
> x86_64-montavista-linux-gnu-g++ (MontaVista Linux G++ 4.7-140716013314) 4.7.0
> 
> /opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++  --print-file-name=libc.so
> /opt/mv_7/install/x86_64/montavista/tools/x86_64-gnu/libexec/../x86_64-montavista-linux-gnu/sys-root/usr/lib/../lib64/libc.so

> On Wed, Oct 24, 2018 at 8:00 PM Padala Dileep <pad...@gm... <mailto:pad...@gm...>> wrote:
> 
>     Hi John,
>     Thanks for your response.
>     Which libc (glibc, uClibc, dietLibc, musl, ...) does this system have?
>     How to check this one?
>     Did you do anything to libc after installation, such as strip symbols? No
>     (Or did the install process itself strip symbols?)   No
> 
>     The libraries generally gets store in a directory /lib on the target, I have treid setting the VALGRIND_PATH to this library path

Complain to MontaVista: they are unfriendly to valgrind, which means unfriendly
to software developers who use MontaVista products. They have compiled ld-linux.so.2
such that 'strlen' has been inlined using SSE* instructions.  That cannot possibly
make any difference in the speed of ld-linux, but it is obnoxious to valgrind.
MontaVista should compile ld-linux with -fno-builtin-strlen .
Meanwhile you should use a software development environment that is friendly to valgrind.

For esoteric technical details see:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1247026/comments/12

Re: [Valgrind-users] Runtime error while running valgrind binary

[John R. <jr...@bi...>]

On 10/24/18, Padala Dileep wrote:
> I have cross compiled the  valgrind binary and trying to run on my target machine.I am getting the below error.
> my target machine:
> uname -a   --  Linux  xxxxxxx  Thu Nov 6 13:58:21 PST 2014 i686 GNU/Linux
> 
> On My build mechine I gave the configure option like below  as the same  compiler we use for the other binaries for the same target
> export CXX=/opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++
> export CC=/opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-gcc
> ./configure  --host=-x86_64-montavista-linux --target=x8_64-montavista-linux  --prefix=/home/xxxxx/valgrind
> i also tried giving target as target-i686. But valgrind executable thrown error " cannot execute binary"
> 
> 
> ~]# ./valgrind ./binaryname
> ==1899== Memcheck, a memory error detector
> ==1899== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==1899== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==1899== Command: ./Frm20xd
> ==1899==
> 
> valgrind:  Fatal error at startup: a function redirection
> valgrind:  which is mandatory for this platform-tool combination
> valgrind:  cannot be set up.  Details of the redirection are:
> valgrind:
> valgrind:  A must-be-redirected function
> valgrind:  whose name matches the pattern:      strlen
> valgrind:  in an object with soname matching:   ld-linux.so.2
> valgrind:  was not found whilst processing
> valgrind:  symbols from the object with soname: ld-linux.so.2

Which libc (glibc, uClibc, dietLibc, musl, ...) does this system have?
Did you do anything to libc after installation, such as strip symbols?
(Or did the install process itself strip symbols?)

Valgrind's message is crystal clear: ld-linux.so.2 does not export 'strlen',
which is required for sane operation of valgrind (actually, to prevent
"false positive" complaints from memcheck about typical code in strlen
that is too hard to recognize and analyze quickly.)
Also, run "readelf --segments ./Frm20xd" and check the [PT_]INTERP
for the exact path to ld-linux.so.2.

You should do what valgrind's message says: install the debug symbols
for your libc.  If you cannot do that, then you cannot run memcheck.

> valgrind:
> valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
> valgrind:  package on this machine.  (2, longer term): ask the packagers
> valgrind:  for your Linux distribution to please in future ship a non-
> valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
> valgrind:  that exports the above-named function using the standard
> valgrind:  calling conventions for this platform.  The package you need
> valgrind:  to install for fix (1) is called
> valgrind:
> valgrind:    On Debian, Ubuntu:                 libc6-dbg
> valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
> valgrind:
> valgrind:  Note that if you are debugging a 32 bit process on a
> valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
> valgrind:  package (e.g. libc6-dbg:i386).
> valgrind:

[Valgrind-users] Runtime error while running valgrind binary

[Padala D. <pad...@gm...>]

Hi
I have cross compiled the  valgrind binary and trying to run on my target
machine.I am getting the below error.
my target machine:
uname -a   --  Linux  xxxxxxx  Thu Nov 6 13:58:21 PST 2014 i686 GNU/Linux

On My build mechine I gave the configure option like below  as the same
compiler we use for the other binaries for the same target
export
CXX=/opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-g++
export
CC=/opt/mv_7/x86_64/tools/x86_64-gnu/bin/x86_64-montavista-linux-gnu-gcc
./configure  --host=-x86_64-montavista-linux
--target=x8_64-montavista-linux  --prefix=/home/xxxxx/valgrind
i also tried giving target as target-i686. But valgrind executable thrown
error " cannot execute binary"


~]# ./valgrind ./binaryname
==1899== Memcheck, a memory error detector
==1899== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1899== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==1899== Command: ./Frm20xd
==1899==

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux.so.2
valgrind:
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:
valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:

Thanks & Regards
Dileep Padala

[Valgrind-users] Valgrind-3.14.0 is available

[Julian S. <js...@ac...>]

We are pleased to announce a new release of Valgrind, version 3.14.0,
available from http://www.valgrind.org.

3.14.0 updates support for existing platforms.  There are, as ever, many
refinements and bug fixes.  The release notes below give more details.

Our thanks to all those who contribute to Valgrind's development.  This
release represents a great deal of time, energy and effort on the part of many
people.

Unfortunately the Solaris port no longer has a maintainer.  If you have some
familiarity with low level Solaris system programming and would like to help
out, please get in touch.  We are also looking for further assistance with the
MacOS port.

Happy and productive debugging and profiling,

-- The Valgrind Developers


Release 3.14.0 (9 October 2018)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3.14.0 is a feature release with many improvements and the usual collection of
bug fixes.

This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux,
PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux,
MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android,
X86/Solaris, AMD64/Solaris and AMD64/MacOSX 10.12.  There is also preliminary
support for X86/macOS 10.13, AMD64/macOS 10.13.

* ==================== CORE CHANGES ===================

* The new option --keep-debuginfo=no|yes (default no) can be used to retain
  debug info for unloaded code.  This allows saved stack traces (e.g. for
  memory leaks) to include file/line info for code that has been dlclose'd (or
  similar).  See the user manual for more information and known limitations.

* Ability to specify suppressions based on source file name and line number.

* Majorly overhauled register allocator.  No end-user changes, but the JIT
  generates code a bit more quickly now.

* ================== PLATFORM CHANGES =================

* Preliminary support for macOS 10.13 has been added.

* mips: support for MIPS32/MIPS64 Revision 6 has been added.

* mips: support for MIPS SIMD architecture (MSA) has been added.

* mips: support for MIPS N32 ABI has been added.

* s390: partial support for vector instructions (integer and string) has been
  added.

* ==================== TOOL CHANGES ====================

* Helgrind: Addition of a flag
  --delta-stacktrace=no|yes [yes on linux amd64/x86]
  which specifies how full history stack traces should be computed.
  Setting this to =yes can speed up Helgrind by 25% when using
  --history-level=full.

* Memcheck: reduced false positive rate for optimised code created by Clang 6
  / LLVM 6 on x86, amd64 and arm64.  In particular, Memcheck analyses code
  blocks more carefully to determine where it can avoid expensive definedness
  checks without loss of precision.  This is controlled by the flag
  --expensive-definedness-checks=no|auto|yes [auto].

* ==================== OTHER CHANGES ====================

* Valgrind is now buildable with link-time optimisation (LTO).  A new
  configure option --enable-lto=yes allows building Valgrind with LTO.  If the
  toolchain supports it, this produces a smaller/faster Valgrind (up to 10%).
  Note that if you are doing Valgrind development, --enable-lto=yes massively
  slows down the build process.

* ==================== FIXED BUGS ====================

The following bugs have been fixed or resolved.  Note that "n-i-bz"
stands for "not in bugzilla" -- that is, a bug that was reported to us
but never got a bugzilla entry.  We encourage you to file bugs in
bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
than mailing the developers (or mailing lists) directly -- bugs that
are not entered into bugzilla tend to get forgotten about or ignored.

To see details of a given bug, visit
  https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed below.

79362   Debug info is lost for .so files when they are dlclose'd
208052  strlcpy error when n = 0
255603  exp-sgcheck Assertion '!already_present' failed
338252  building valgrind with -flto (link time optimisation) fails
345763  MIPS N32 ABI support
368913  WARNING: unhandled arm64-linux syscall: 117 (ptrace)
        == 388664  unhandled arm64-linux syscall: 117  (ptrace)
372347  Replacement problem of the additional c++14/c++17 new/delete operators
373069  memcheck/tests/leak_cpp_interior fails with GCC 5.1+
376257  helgrind history full speed up using a cached stack
379373  Fix syscall param msg->desc.port.name points to uninitialised byte(s)
        on macOS 10.12
379748  Fix missing pselect syscall (OS X 10.11)
379754  Fix missing syscall ulock_wait (OS X 10.12)
380397  s390x: __GI_strcspn() replacemenet needed
381162  possible array overrun in VEX register allocator
381272  ppc64 doesn't compile test_isa_2_06_partx.c without VSX support
381274  powerpc too chatty even with --sigill-diagnostics=no
381289  epoll_pwait can have a NULL sigmask
381553  VEX register allocator v3
381556  arm64: Handle feature registers access on 4.11 Linux kernel or later
381769  Use ucontext_t instead of struct ucontext
381805  arm32 needs ld.so index hardwire for new glibc security fixes
382256  gz compiler flag test doesn't work for gold
382407  vg_perf needs "--terse" command line option
382515  "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/[..]
382563  MIPS MSA ASE support
382998  xml-socket doesn't work
383275  massif: m_xarray.c:162 (ensureSpaceXA): Assertion '!xa->arr' failed
383723  Fix missing kevent_qos syscall (macOS 10.11)
        == 385604  illegal hardware instruction (OpenCV cv::namedWindow)
384096  Mention AddrCheck at Memcheck's command line option [..]
384230  vex x86->IR: 0x67 0xE8 0xAB 0x68
        == 384156  vex x86->IR: 0x67 0xE8 0x6B 0x6A
        == 386115  vex x86->IR: 0x67 0xE8 0xD3 0x8B any program
        == 388407  vex x86->IR: 0x67 0xE8 0xAB 0x29
        == 394903  vex x86->IR: 0x67 0xE8 0x1B 0xDA
384337  performance improvements to VEX register allocator v2 and v3
384526  reduce number of spill insns generated by VEX register allocator v3
384584  Callee saved regs listed first for AMD64, X86, and PPC architectures
384631  Sanitise client args as printed with -v
384633  Add a simple progress-reporting facility
384987  VEX regalloc: allocate caller-save registers for short lived vregs
385055  PPC VEX temporary storage exhausted
385182  PPC64 is missing support for the DSCR
385183  PPC64, Add support for xscmpeqdp, xscmpgtdp, xscmpgedp, xsmincdp
385207  PPC64, generate_store_FPRF() generates too many Iops
385208  PPC64, xxperm instruction exhausts temporary memory
385210  PPC64, vpermr instruction could exhaust temporary memory
385279  unhandled syscall: mach:43 (mach_generate_activity_id)
        == 395136  valgrind: m_syswrap/syswrap-main.c:438 (Bool eq_Syscall[..]
        == 387045  Valgrind crashing on High Sierra when testing any newly [..]
385334  PPC64, fix vpermr, xxperm, xxpermr mask value.
385408  s390x: z13 vector "support" instructions not implemented
385409  s390x: z13 vector integer instructions not implemented
385410  s390x: z13 vector string instructions not implemented
385412  s390x: new non-vector z13 instructions not implemented
385868  glibc ld.so _dl_runtime_resolve_avx_slow conditional jump warning.
385912  none/tests/rlimit_nofile fails on newer glibc/kernel.
385939  Optionally exit on the first error
386318  valgrind.org/info/tools.html is missing SGCheck
386425  running valgrind + wine on armv7l gives illegal opcode
386397  PPC64, valgrind truncates powerpc timebase to 32-bits.
387410  MIPSr6 support
387664  Memcheck: make expensive-definedness-checks be the default
387712  s390x cgijnl reports Conditional jump depends on uninitialised value
387766  asm shifts cause false positive "Conditional jump or move depends
        on uninitialised value"
387773  .gnu_debugaltlink paths resolve relative to .debug file, not symlink
388174  valgrind with Wine quits with "Assertion 'cfsi_fits' failed"
388786  Support bpf syscall in amd64 Linux
388862  Add replacements for wmemchr and wcsnlen on Linux
389065  valgrind meets gcc flag -Wlogical-op
389373  exp-sgcheck the 'impossible' happened as Ist_LoadG is not instrumented
390471  suppression by specification of source-file line number
390723  make xtree dump files world wide readable, similar to log files
391164  constraint bug in tests/ppc64/test_isa_2_07_part1.c for mtfprwa
391861  Massif Assertion 'n_ips >= 1 && n_ips <= VG_(clo_backtrace_size)'
392118  unhandled amd64-linux syscall: 332 (statx)
392449  callgrind not clearing the number of calls properly
393017  Add missing support for xsmaxcdp instruction, bug fixes for xsmincdp,
        lxssp, stxssp and stxvl instructions.
393023  callgrind_control risks using the wrong vgdb
393062  build-id ELF phdrs read causes "debuginfo reader: ensure_valid failed"
393099  posix_memalign() invalid write if alignment == 0
393146  failing assert "is_DebugInfo_active(di)"
395709  PPC64 is missing support for the xvnegsp instruction
395682  Accept read-only PT_LOAD segments and .rodata by ld -z separate-code
        == 384727
396475  valgrind OS-X build: config.h not found (out-of-tree macOS builds)
395991  arm-linux: wine's unit tests enter a signal delivery loop [..]
396839  s390x: Trap instructions not implemented
396887  arch_prctl should return EINVAL on unknown option
        == 397286 crash before launching binary (Unsupported arch_prctl option)
        == 397393 valgrind: the 'impossible' happened: (Archlinux)
        == 397521 valgrind: the 'impossible' happened: Unsupported [..]
396906  compile tests failure on mips32-linux: broken inline asm in tests on
        mips32-linux
397012  glibc ld.so uses arch_prctl on i386
397089  amd64: Incorrect decoding of three-register vmovss/vmovsd opcode 11h
397354  utimensat should ignore timespec tv_sec if tv_nsec is UTIME_NOW/OMIT
397424  glibc 2.27 and gdb_server tests
398028  Assertion `cfsi_fits` failing in simple C program
398066  s390x: cgijl dep1, 0 reports false unitialised values warning

n-i-bz  Fix missing workq_ops operations (macOS)
n-i-bz  fix bug in strspn replacement
n-i-bz  Add support for the Linux BLKFLSBUF ioctl
n-i-bz  Add support for the Linux BLKREPORTZONE and BLKRESETZONE ioctls
n-i-bz  Fix possible stack trashing by semctl syscall wrapping
n-i-bz  Add support for the Linux membarrier() system call
n-i-bz  x86 front end: recognise and handle UD2 correctly
n-i-bz  Signal delivery for x86-linux: ensure that the stack pointer is
        correctly aligned before entering the handler.

(3.14.0.RC1: 30 September 2018, git c2aeea2d28acb0639bcc8cc1e4ab115067db1eae)
(3.14.0.RC2: 3 October 2018, git 3e214c4858a6fdd5697e767543a0c19e30505582)
(3.14.0:     9 October 2018, git 353a3587bb0e2757411f9138f5e936728ed6cc4f)

Re: [Valgrind-users] Program in valgrind behaves slightly different comparing to normal run

[Dallman, J. <joh...@si...>]

> As a Valgrind user, I see few ways to get different results with valgrind :

Another possibility is that the OP has a memory management bug, and the inevitably slightly different memory layout when running under Valgrind can trigger it. I have not seen this with Valgrind, but I have seen it when moving to new versions of an operating system when the memory management has been changed significantly.

--
John Dallman
-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

Re: [Valgrind-users] Program in valgrind behaves slightly different comparing to normal run

[Bruno L. <lat...@tu...>]

Hi,

As a Valgrind user, I see few ways to get different results with valgrind :

- your code can use introspection: depending on memory footprint or 
computation time, you may choose an algorithm or an other. Usually you 
can configure your code to avoid it temporary.

- your binary may contain x87 floating point instructions (with 80bits). 
Valgrind is not able to guarantee the reproducibility (as well you are 
not able to guarantee the portability of your code upon different 
processors). For more details you can search x87 on page 
http://valgrind.org/docs/manual/manual-core.html#manual-core.limits . By 
default gcc should avoid them except if you use options like 
--mfpmath=387 , if you use library with x87 hard-coded with assembly 
(like openblas) or if you use long double.

- your binary may modify the floating-point register to change the 
rounding-mode and Valgrind will ignore it. The valgrind option 
--show-emwarns=yes is for me really useful (whereas described as 
"usually not interesting" in the man page).


To pinpoint branch divergences, you can compile your code with coverage 
options (-fprofile-arcs -ftest-coverage), and then compare the  covers 
produced with gcov (with and without valgrind) with a graphical diff. If 
(and only if) you are familiar with code coverage it is really easy. 
This trick is often used successfully (but not always) with Verrou 
(Warning advertising) a valgrind tool to detect floating point rounding 
error.


I  hope this helps

Bruno Lathuilière

On 10/14/18 11:14 PM, olologin wrote:
> Hi everyone,
>
> First of all I want to thank everyone involved valgrind development, 
> this set of tools, especially memcheck and helgrind saved me a lot of 
> time. There were so many hard-to-find bugs in our code that were found 
> only thanks to these tools.
>
> Now to the question: I've been using memcheck and helgrind for almost 
> a year now, and recently I noticed small instability in results 
> provided by our code. For example if I run my program 10 times with 
> the same output, 5/10 times I get wrong output, and I cannot 
> understand why. So I tried memcheck, but when I run my software in it 
> I always get right output, no matter how often I rerun it - output is 
> always stable, and of course memcheck doesn't report any issues. Same 
> issue happens with helgrind. I can suspect one of dynamic libraries 
> for this instability, but I cannot find exact place that causes this 
> issue. I have sources of that library, but it's quite massive, and I'm 
> not original developer of it and unfortunately I cannot show it since 
> it's closed-source. Most probably this issue is not caused by 
> race-conditions, because it happens even when I run everything in 
> single thread.
>
> So far I tried to play with:
> --smc-check=all
> --redzone-size=*
> --fair-sched=yes
> --expensive-definedness-check=yes
>
>
> Is there anything else I can try? I feel like there is some legitimate 
> way of executing random branch of code, and somehow when I launch my 
> program in valgrind - it always runs only good parts of code, this is 
> why I don't see my program failing, and I don't see any issues 
> reported in valgrind. But is there a way to make it run in same way as 
> without valgrind? I mean to make it produce bad output in valgrind?
>
> I'm using valgrind-3.12.0, my program is compiled with gcc6.3
>
> Thanks in advance.
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Program in valgrind behaves slightly different comparing to normal run

[olologin <olo...@gm...>]

Hi everyone,

First of all I want to thank everyone involved valgrind development, 
this set of tools, especially memcheck and helgrind saved me a lot of 
time. There were so many hard-to-find bugs in our code that were found 
only thanks to these tools.

Now to the question: I've been using memcheck and helgrind for almost a 
year now, and recently I noticed small instability in results provided 
by our code. For example if I run my program 10 times with the same 
output, 5/10 times I get wrong output, and I cannot understand why. So I 
tried memcheck, but when I run my software in it I always get right 
output, no matter how often I rerun it - output is always stable, and of 
course memcheck doesn't report any issues. Same issue happens with 
helgrind. I can suspect one of dynamic libraries for this instability, 
but I cannot find exact place that causes this issue. I have sources of 
that library, but it's quite massive, and I'm not original developer of 
it and unfortunately I cannot show it since it's closed-source. Most 
probably this issue is not caused by race-conditions, because it happens 
even when I run everything in single thread.

So far I tried to play with:
--smc-check=all
--redzone-size=*
--fair-sched=yes
--expensive-definedness-check=yes


Is there anything else I can try? I feel like there is some legitimate 
way of executing random branch of code, and somehow when I launch my 
program in valgrind - it always runs only good parts of code, this is 
why I don't see my program failing, and I don't see any issues reported 
in valgrind. But is there a way to make it run in same way as without 
valgrind? I mean to make it produce bad output in valgrind?

I'm using valgrind-3.12.0, my program is compiled with gcc6.3

Thanks in advance.

Re: [Valgrind-users] [Valgrind-developers] valgrind-3.14.0.RC2 is available for testing

[Paul F. <pj...@wa...>]

> On 6 Oct 2018, at 01:05, Roger Light <rog...@ce...> wrote:
> 
> Hello,
> 
> I built and tested on a Mac with OS X version 10.13.6. I have the same problem with the tarball, but the git checkout built just fine.
> 
> make regtest produced:
> 
> == 643 tests, 328 stderr failures, 83 stdout failures, 1 stderrB failure, 1 stdoutB failure, 31 post failures ==
> 
> Which is a lot of errors. But I may have done something wrong (build and test was: ./autogen.sh ; ./configure ; make -j8 ; make regtest)
> 
> Cheers,
> 
> Roger


Hi

Similar results here

macOS 10.13.6
== 643 tests, 328 stderr failures, 84 stdout failures, 1 stderrB failure, 1 stdoutB failure, 31 post failures ==

Solaris 11.3
== 747 tests, 13 stderr failures, 3 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==

Fedora 24
== 766 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==


A+
Paul

Re: [Valgrind-users] [Valgrind-developers] valgrind-3.14.0.RC2 is available for testing

[Philippe W. <phi...@sk...>]

If you try to build the RC2 but from the git repository,
does that work better ?

If the same git version builds/runs ok, then it is probably
just a tar ball packaging problem ...

Philippe


On Thu, 2018-10-04 at 14:41 -0700, Jonathan Leffler wrote:
> Hi,
> 
> What is the intended support status of macOS 10.13.x High Sierra?  What about macOS 10.14 Mojave?
> 
> Some time ago, I downloaded an interim version of Valgrind from Git (git pull) and amongst other files there was a darwin17.supp file . That seems to be missing from the 3.14.0.RC2 tar file.  Consequently, although it configured OK on macOS 10.13.6, it failed to build at a very early stage.  I've not yet tried the build on Mojave, but that would presumably fail because of a missing darwin18.supp file.
> 
> The commit I have that has worked on macOS 10.13.x was:
> 
> commit 92d6a538862a784156ee5fff297eb7daba733127 (HEAD -> master, origin/master, origin/HEAD)
> Author: Rhys Kidd <rhy...@gm...>
> Date:   Sun Jun 3 12:40:13 2018 -0400
> 
>     Fix missing kevent_qos syscall (macOS 10.11). bz#383723
> 
> The version built on High Sierra ran on Mojave, but had a new set of warnings — extensive ones.  I assume these should simply be built into a suppressions file for Mojave, in the absence of any better solution.
> 
> 
> On Wed, Oct 3, 2018 at 8:54 AM Julian Seward <js...@ac...> wrote:
> > Greetings.
> > 
> > Per the subject line, valgrind-3.14.0.RC2 is available for testing, at:
> > 
> >   ftp://sourceware.org/pub/valgrind/valgrind-3.14.0.RC2.tar.bz2
> >   https://sourceware.org/pub/valgrind/valgrind-3.14.0.RC2.tar.bz2
> >   (md5 = e92f8816973396edd6d0cbcd820ccca0)
> > 
> > Please give it a try on systems, and in configurations, which are important
> > for you, and report any failures (and successes!) here.  I propose to make the
> > final 3.14.0 release on Tuesday 9 October if no serious breakage is reported.
> > 
> > As ever, the NEWS file in the tarball lists the new features and fixed bugs in
> > this release.
> > 
> > J
> > 
> > 
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
> > 
> 
> 
> -- 
> Jonathan Leffler <jon...@gm...>  #include <disclaimer.h>
> Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
> "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers

Re: [Valgrind-users] valgrind-3.14.0.RC2 is available for testing

[Mark W. <ma...@kl...>]

On Wed, Oct 03, 2018 at 05:53:57PM +0200, Julian Seward wrote:
> Per the subject line, valgrind-3.14.0.RC2 is available for testing, at:
> 
>   ftp://sourceware.org/pub/valgrind/valgrind-3.14.0.RC2.tar.bz2
>   https://sourceware.org/pub/valgrind/valgrind-3.14.0.RC2.tar.bz2
>   (md5 = e92f8816973396edd6d0cbcd820ccca0)
> 
> Please give it a try on systems, and in configurations, which are important
> for you, and report any failures (and successes!) here.  I propose to make the
> final 3.14.0 release on Tuesday 9 October if no serious breakage is reported.

For Fedora users there are packages here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1149947

And for CentOS (and Fedora 28) users there are packages here:
https://copr.fedorainfracloud.org/coprs/mjw/valgrind-3.14.0/

Cheers,

Mark

[Valgrind-users] valgrind-3.14.0.RC2 is available for testing

[Julian S. <js...@ac...>]

Greetings.

Per the subject line, valgrind-3.14.0.RC2 is available for testing, at:

  ftp://sourceware.org/pub/valgrind/valgrind-3.14.0.RC2.tar.bz2
  https://sourceware.org/pub/valgrind/valgrind-3.14.0.RC2.tar.bz2
  (md5 = e92f8816973396edd6d0cbcd820ccca0)

Please give it a try on systems, and in configurations, which are important
for you, and report any failures (and successes!) here.  I propose to make the
final 3.14.0 release on Tuesday 9 October if no serious breakage is reported.

As ever, the NEWS file in the tarball lists the new features and fixed bugs in
this release.

J

Re: [Valgrind-users] helgrind and c++ atomic_flag

[David F. <fa...@kd...>]

On mardi 25 septembre 2018 16:17:48 CEST John Perry wrote:
> > On Sep 25, 2018, at 7:02 AM, Tom Hughes <to...@co...> wrote:
> > 
> > I don't believe helgrind makes any attempt to observe atomic
> > operations so it is entirely unaware of them and of any effect
> > they might have on the thread correctness of a program.
> > 
> > It would be hard to do because where the compiler is able to
> > generate direction instructions for the atomic there will be no
> > function call to intercept, and as there won't necessarily be a
> > one-one mapping from atomic operations to CPU instructions it
> > is hard to determine what the original operation was by
> > observing the instruction stream.
> 
> Thank you! This comes as a huge relief, because I first noticed the issue in a program I was writing where I used that approach and worried I was doing something very, very bad. Now I can rest easy. Or at least easier.

You want to use TSAN (thread-sanitizer) instead (preferably with clang and libc++, in my experience), which supports atomic operations.

Sorry for advertising a competing solution on the valgrind mailing-list ;-)
I admit I'm much less of a helgrind fan since tsan started to work well.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] helgrind and c++ atomic_flag

[John P. <Joh...@us...>]

> On Sep 25, 2018, at 7:02 AM, Tom Hughes <to...@co...> wrote:
> 
> I don't believe helgrind makes any attempt to observe atomic
> operations so it is entirely unaware of them and of any effect
> they might have on the thread correctness of a program.
> 
> It would be hard to do because where the compiler is able to
> generate direction instructions for the atomic there will be no
> function call to intercept, and as there won't necessarily be a
> one-one mapping from atomic operations to CPU instructions it
> is hard to determine what the original operation was by
> observing the instruction stream.

Thank you! This comes as a huge relief, because I first noticed the issue in a program I was writing where I used that approach and worried I was doing something very, very bad. Now I can rest easy. Or at least easier.

regards
john perry

-- 
John Edward Perry, III
Associate Professor, Dept of Mathematics, University of Southern Mississippi
Undergraduate Program Lead, Mathematics BS
joh...@us...
A man with no regrets has either no past or no conscience.