Re: [Valgrind-users] how to proceed when faced with malloc error

[Julian Seward]

This generally happens when memory errors in the application under test
(here, "btserver") are so bad they wind up trashing Valgrind's storage
too.  If Valgrind has reported memory errors prior to this point, try
fixing them first.

J

--19817-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - 
exiting

--19817-- si_code=128;  Faulting address: 0x0;  sp: 0x100993be30

valgrind: the 'impossible' happened:
    Killed by fatal signal

host stacktrace:
==19817==    at 0x580492FF: get_bszB_as_is (m_mallocfree.c:302)
==19817==    by 0x580492FF: get_bszB (m_mallocfree.c:314)
==19817==    by 0x580492FF: vgPlain_arena_malloc (m_mallocfree.c:1819)
==19817==    by 0x58004D74: vgMemCheck_new_block (mc_malloc_wrappers.c:370)
==19817==    by 0x58004F99: vgMemCheck___builtin_new (mc_malloc_wrappers.c:415)
==19817==    by 0x58093FD5: do_client_request (scheduler.c:1979)
==19817==    by 0x58093FD5: vgPlain_scheduler (scheduler.c:1542)
==19817==    by 0x580DA8DA: thread_wrapper (syswrap-linux.c:102)
==19817==    by 0x580DA8DA: run_a_thread_NORETURN (syswrap-linux.c:155)

sched status:
   running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 19817)
==19817==    at 0x4841EF1: operator new(unsigned long) (vg_replace_malloc.c:472)
==19817==    by 0x60FFB3: Card::checkNewPort(LFInfo&, String const&, char 
const*, bool, char const*, bool&, bool&, unsigned int) (Card.cc:7510)
==19817==    by 0x611337: Card::discoverDevices(LFInfo&, char const*, bool) 
(Card.cc:8205)

==19817==    by 0x84815E: btserver_main(int, char**) (main.cc:1034)
==19817==    by 0x844F64: main (main.cc:157)
client stack range: [0x1FFEFEA000 0x1FFF000FFF] client SP: 0x1FFEFFDB30
valgrind stack range: [0x100983C000 0x100993BFFF] top usage: 13936 of 1048576




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] memcheck is getting SIGKILLed before leak report is output

[Julian Seward]

Is there anything that can be done with memcheck to make it consume less memory?


First of all, figure out whether memcheck got sigkilled because the machine
ran out of space, or because you hit some shell limit/ulimit.  In the former
case, you can then try adding swap space to the machine.  In the latter case
you'll need to mess with the shell's ulimit settings.

You could also try reducing the (data) size of the workload.

Massif and Memcheck are different tools and do largely different things.
Whether or not you can use one or the other depends a lot on the specifics
of what problem you're trying to solve.

J



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] memcheck is getting SIGKILLed before leak report is output

[Julian Seward]

On 05/08/2022 16:08, Tom Hughes via Valgrind-users wrote:


If you want to know for sure who killed it then strace it while
it runs and it should show you who sends the signel but my bet is
that it's the kernel.


Or possibly watch `dmesg -w` running in another shell.

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Possible to suppress low block count loss records?

[Julian Seward]

On 13/07/2022 16:38, Bresalier, Rob (Nokia - US/Murray Hill) wrote:

We are trying to track down a suspected place in our code that keeps 
accumulating memory in a 'still reachable'.


It sounds like you're trying to track down a "process lifetime" leak.

You'd be better off using one of the heap profiling tools for that,
either massif (--tool=massif) or dhat (--tool=dhat), but probably massif.

You'll need to ask your package manager to install the massif-visualizer GUI.

Run with --tool=massif --num-callers=12 (or 16 or whatever).  Use the GUI
to look at the resulting profile.  After a bit of poking around it should
be obvious where all your allocation is coming from.

J




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Memory leak not detected

[Julian Seward]

Any ideas why this memory leak is not being detected by valgrind?


Because it's not really possible to do so.  Consider the problem of knowing
when an mmap-d page is no longer in use.  Those pages are presumably managed
by your app, in some way that is unknown to Valgrind/Memcheck, hence it has
no way to know when a page is, logically speaking, leaked.

By contrast, blocks in the normal malloc/free heap are "managed" by a
simple protocol (calling malloc, then free) that Memcheck knows about.
So it can figure out when a block is leaked by checking whether any
pointers to it exist.  Even then, that's a heuristic hack: you could
conceivably represent a block address into two values, which, when added
together, produce the address.  Then Memcheck will believe the block to
be leaked, even though you could regain access to it merely by adding
the two values together.

J



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.18.1 is available

[Julian Seward]

We are pleased to announce a new release of Valgrind, version 3.18.1,
available from http://valgrind.org/downloads/current.html.

3.18.1 fixes a number of bugs and adds support for glibc-2.34, and for new
platforms x86/FreeBSD and amd64/FreeBSD.  Debuginfo reading is faster, and
Rust demangling has been improved. For PPC64, ISA 3.1 support has been
completed, and some newer ARM64 and S390 instructions are also supported.  See
the release notes below for details of changes.  Note, 3.18.0 had no formal
release -- it was pulled at the last minute due to a packaging problem.

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.

Happy and productive debugging and profiling,

-- The Valgrind Developers


Release 3.18.0 (15 Oct 2021)


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, AMD64/MacOSX 10.12, X86/FreeBSD and
AMD64/FreeBSD.  There is also preliminary support for X86/macOS 10.13,
AMD64/macOS 10.13 and nanoMIPS/Linux.

*  CORE CHANGES ===

* The libiberty demangler has been updated, which brings support for
  Rust v0 name demangling

* __libc_freeres isn't called anymore after the program recieves a
  fatal signal. Causing some internal glibc resources to hang around,
  but preventing any crashes after the program has ended.

* The DWARF reader is now very much faster at startup when just
  --read-inline-info=yes (the default in most cases) is given.

* glibc 2.34, which moved various functions from libpthread.so into
  libc.so, is now supported.

* == PLATFORM CHANGES =

* arm64:

  - v8.2 scalar and vector FABD, FACGE, FACGT and FADD.
  - v8.2 FP compare & conditional compare instructions.
  - Zero variants of v8.2 FP compare instructions.

* s390:

  - Support the miscellaneous-instruction-extensions facility 3 and
the vector-enhancements facility 2.  This enables programs
compiled with "-march=arch13" or "-march=z15" to be executed
under Valgrind.

* ppc64:

  - ISA 3.1 support is now complete
  - ISA 3.0 support for the darn instruction added.
  - ISA 3.0 support for the vector system call instruction scv added.
  - ISA 3.0 support for the copy, paste and cpabort instructions added.

* Support for X86/FreeBSD and AMD64/FreeBSD has been added.

*  OTHER CHANGES 

* Memcheck on amd64: minor fixes to remove some false positive
  undef-value errors

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

208531  [PATCH]: FreeBSD support for valgrind
368960  WARNING: unhandled amd64-linux syscall: 163 (acct)
407589  [Linux] Add support for C11 aligned_alloc() and GNU reallocarray()
423963  Error in child thread when CLONE_PIDFD is used
426148  crash with "impossible happened" when running BPF CO-RE programs
429375  PPC ISA 3.1 support is missing, part 9
431157  PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
431306  Update demangler to support Rust v0 name mangling
432387  s390x: z15 instructions support
433437  FreeBSD support, part 1
433438  FreeBSD support, part 2
433439  FreeBSD support, part 3
433469  FreeBSD support, part 4
433473  FreeBSD support, part 5
433477  FreeBSD support, part 6
433479  FreeBSD support, part 7
433504  FreeBSD support, part 8
433506  FreeBSD support, part 9
433507  FreeBSD support, part 10
433508  FreeBSD support, part 11
433510  FreeBSD support, part 12
433801  PPC ISA 3.1 support is missing, part 10 (ISA 3.1 support complete)
433863  s390x: memcheck/tests/s390x/{cds,cs,csg} failures
434296  s390x: False-positive memcheck diagnostics from vector string
instructions
434840  PPC64 darn instruction not supported
435665  PPC ISA 3.0 copy, paste, cpabort instructions are not supported
435908  valgrind tries to fetch from deubginfod for files which already
have debug information
438871  unhandled instruction bytes: 0xF3 0x49 0xF 0x6F 0x9C 0x24 0x60 0x2
439046  valgrind is unusably large when linked with lld
439090  Implement close_range(2)
439326  Valgrind 3.17.0 won't compile with Intel 2021 oneAPI compilers
439590  glibc-2.34 breaks suppressions against obj:*/lib*/libc-2.*so*
440670  unhandled ppc64le-linux syscall: 252 statfs64 and 253 fstatfs64
440906  Fix impossible constraint issue in P10 testcase.
441512  

[Valgrind-users] valgrind-3.16.1 is available

[Julian Seward]

We are pleased to announce a new release of Valgrind, version 3.16.1,
available from http://valgrind.org/downloads/current.html.  The source tarball
is signed with the PGP key at the bottom of this message.

3.16.1 updates support for existing platforms and reduces Memcheck's false
positive rate on optimised code generated by Clang and GCC.  There are, as ever,
many refinements and bug fixes.  The release notes below give more details.

A 3.16.0 tarball does exist, but was never announced due to the late discovery
of two critical bugs in it.  These are fixed in 3.16.1.  We recommend you use
or distribute 3.16.1 and not 3.16.0.

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.

Happy and productive debugging and profiling,

-- The Valgrind Developers



Release 3.16.1 (22 June 2020)
~

3.16.1 fixes two critical bugs discovered after 3.16.0 was frozen.  It also
fixes character encoding problems in the documentation HTML.

422677  PPC sync instruction L field should only be 2 bits in ISA 3.0
422715  32-bit x86: vex: the `impossible' happened: expr_is_guardable:
unhandled expr

(3.16.1, 22 June 2020, 36d6727e1d768333a536f274491e5879cab2c2f7)



Release 3.16.0 (27 May 2020)


3.16.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 and nanoMIPS/Linux.

*  CORE CHANGES ===

* It is now possible to dynamically change the value of many command line
  options while your program (or its children) are running under Valgrind.

  To see the list of dynamically changeable options, run
 "valgrind --help-dyn-options".

  You can change the options from the shell by using vgdb to launch
  the monitor command "v.clo ...".
  The same monitor command can be used from a gdb connected
  to the valgrind gdbserver.
  Your program can also change the dynamically changeable options using
  the client request VALGRIND_CLO_CHANGE(option).

* == PLATFORM CHANGES =

* MIPS: preliminary support for nanoMIPS instruction set has been added.

*  TOOL CHANGES 

* DHAT:

  - The implicit memcpy done by each call to realloc now counts towards the
read and write counts of resized heap blocks, making those counts higher
and more accurate.

* Cachegrind:

  - cg_annotate's --auto and --show-percs options now default to 'yes', because
they are usually wanted.

* Callgrind:

  - callgrind_annotate's --auto and --show-percs options now default to 'yes',
because they are usually wanted.

  - The command option --collect-systime has been enhanced to specify
the unit used to record the elapsed time spent during system calls.
The command option now accepts the values no|yes|msec|usec|nsec,
where yes is a synonym of msec.  When giving the value nsec, the
system cpu time of system calls is also recorded.

* Memcheck:

  - Several memcheck options are now dynamically changeable.
Use  valgrind --help-dyn-options  to list them.

  - The release 3.15 introduced a backward incompatible change for
some suppression entries related to preadv and pwritev syscalls.
When reading a suppression entry using the unsupported 3.14 format,
valgrind will now produce a warning to say the suppression entry will not
work, and suggest the needed change.

  - Significantly fewer false positive errors on optimised code generated by
Clang and GCC.  In particular, Memcheck now deals better with the
situation where the compiler will transform C-level "A && B" into "B && A"
under certain circumstances (in which the transformation is valid).
Handling of integer equality/non-equality checks on partially defined
values is also improved on some architectures.

* exp-sgcheck:

  - The experimental Stack and Global Array Checking tool has been removed.
It only ever worked on x86 and amd64, and even on those it had a
high false positive rate and was slow.  An alternative for detecting
stack and global array overruns is using the AddressSanitizer (ASAN)
facility of the GCC and Clang compilers, which require you to rebuild
your code with -fsanitize=address.

*  OTHER CHANGES 

* New and modified GDB server monitor features:

  - Option -T tells vgdb to output a timestamp in the vgdb information messages.

  - The gdbserver monitor commands that require an address and an optional
length argument now accepts the 

Re: [Valgrind-users] DHAT speed

[Julian Seward]

That doesn't sound right.  I use DHAT extensively and expect a slowdown of
perhaps 50:1, maybe less.  What you're describing is a slowdown factor of
at least several thousand.

Bear in mind though that (1) V sequentialises thread execution, which wil
make a big difference if the program is heavily multithreaded, and (2)
I suspect dhat's scheme of looking up all memory accesses in an AVL tree
(of malloc'd blocks) doesn't scale all that well if you have tens of
millions of blocks.

Can you run it on a smaller workload?

J

On 26/05/2020 09:21, Paul FLOYD wrote:

Hi
  
I'm running DHAT on what I consider to be a relatively small example. Standalone the executable runs in a bit under 10 minutes. Based on the CPU time that we print after every 10% of progress, under DHAT the same executable is going to take about 422 hours - about two and a half weeks.
  
Does anyone have any ideas what could be causing it to be so slow? Indeed, is this the sort of slowdown that I should be expecting with DHAT? The executable is intensive in both memory and floating point. Probably not helping matters, the data structures that I want to look at are over 1kB in size so I tweaked the HISTOGRAM_SIZE_LIMIT to bump it up to 2kb.
  
On the DHAT side, I have thought of trying to use some macro hackery to try to inline the avl comparator function calls. Otherwise I don't have much in the way of other ideas, and DHAT doesn't have any cli options to tweak things.
  
A+

Paul
  




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users





___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[Julian Seward]

You can't easily avoid this problem, because it occurs in a system library,
not in your own code:

==306851== valgrind: Unrecognised instruction at address 0x6ddf581.
==306851==at 0x6DDF581: opal_pointer_array_construct (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)

Possibly your least-worst option is to talk with the people who built/
installed OpenMPI on the machine, to see if you can get a build that
doesn't use AVX512 instructions.

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.16.0.RC2 is available for testing

[Julian Seward]

Greetings.

A first release candidate for 3.16.0 is available at
https://sourceware.org/pub/valgrind/valgrind-3.16.0.RC2.tar.bz2
(md5 = 21ac87434ed32bcfe5ea86a0978440ba)

Please give it a try on platforms that are important for you.  If no serious
issues are reported, the 3.16.0 final release will happen on 25 May, that is,
next Monday.

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] New user and first problem

[Julian Seward]

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5
0x25 0xA8 0x18 0x0
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==377969== valgrind: Unrecognised instruction at address 0xabf9581.
==377969==    at 0xABF9581: opal_pointer_array_construct (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)


It sounds like there's an instruction in libopen-pal.so.40.10.3 that
Valgrind doesn't like.  What CPU does the machine have?

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] seemingly bogus error reports

[Julian Seward]

On 14/09/2019 21:11, Fred Smith wrote:

Hi all!

I'm new to this list, but have used Valgrind many times in the past.

Today I'm making a serious effort to clean up a non-trivial body of code, and 
have run into a number of error reports like this one:


Try again with the trunk now
(git clone git://sourceware.org/git/valgrind.git).  I just pushed a
bunch of changes in, aimed at reducing the false positive level on
optimised code, relating to transformations to do with C-level &&/||
expressions.

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Feature like add-symbol-file for Valgrind

[Julian Seward]

Did you look into using the following option?

--ignore-range-below-sp=-  do not report errors for
 accesses at the given offsets below SP

J

On 18/11/2019 09:02, Jefferson Carpenter wrote:
I'm debugging a mingw-compiled exe running under Wine, and I'm getting some 
invalid reads in chkstk.  Assuming I don't want to "skip past" them but detect 
and suppress them, the most natural thing to do would be to create and use a 
suppressions file.


However, the code that calls into chkstk is loaded outside of the normal 
"dlopen" code path, and neither Valgrind nor GDB loads symbols for it before 
it is jumped into.  With GDB I can use "add-symbol-file" to state where to 
find the symbols for it.  Does Valgrind have a similar option?


Thanks,
Jefferson


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users





___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] No Git tag for v3.15.0

[Julian Seward]

Hi Mark,

> Julian would you mind creating a signed tag for this commit?
> Using the same pgp key you used to sign the release tar ball?
>
> git tag -s -m "valgrind 3.15.0 release" VALGRIND_3_15_0 \
>  608cb11914e5f23d0fc12c61dad29c5c7952a1de
> git push --tags

Done!

J



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Mencheck not giving detailed info on routines in Shared Libraries:

[Julian Seward]

> Valgrind-3.13 (actually I compiled 3.15, but it says 3.13 with Valgrind
> --version)

In that case you're not running the version you compiled.

Try running 3.15 and give it the flag --keep-debuginfo=yes.  Does that help?

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] --track-origins option is not working

[Julian Seward]

I guess that the problem is that the build of valgrind somehow removed
the debug (unwind) information on
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so
and that's why there is no backtrace.  Can you rebuild valgrind so that
the debug information on that file is preserved?

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] POSIX pthread counter (integer) overflow in valgrind drd_vc.c

[Julian Seward]

> drd: drd_vc.c:96 (vgDrd_vc_increment): Assertion 'oldcount <
> vc->vc[i].count' failed.

I suspect (I don't know for sure) that this is a vector clock overflow.
That might happen if your program performed more that 2^32 inter-thread
synchronisation events, for example, mutex lock, unlock, condvar posts
or signals, sem post/wait, thread create/join, etc.  Is that likely?

Can you reduce the problem size (to perhaps a few hundred thousand records)
and see if the failure goes away?

> I don't understand what the semantics of the thread counter "count" is [..]

I suspect that is incremented every time one of the abovementioned thread
events happens.  The mechanism is a bit complex, but a counter overflow could
happen if there is a chain of such thread events (possibly involving multiple
threads) that is more than 2^32 long.

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] valgrind-3.15.0 is available

[Julian Seward]

We are pleased to announce a new release of Valgrind, version 3.15.0,
available from http://valgrind.org/downloads/current.html.  The source tarball
is signed with the PGP key at the bottom of this message.

3.15.0 updates support for existing platforms and adds a major overhaul of the
DHAT heap profiler.  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.15.0 (12 April 2019)
~~

3.15.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 and AMD64/macOS 10.13.

*  CORE CHANGES ===

* The XTree Massif output format now makes use of the information obtained
  when specifying --read-inline-info=yes.

* amd64 (x86_64): the RDRAND and F16C insn set extensions are now supported.

*  TOOL CHANGES 

* DHAT:

  - DHAT been thoroughly overhauled, improved, and given a GUI.  As a result,
it has been promoted from an experimental tool to a regular tool.  Run it
with --tool=dhat instead of --tool=exp-dhat.

  - DHAT now prints only minimal data when the program ends, instead writing
the bulk of the profiling data to a file.  As a result, the --show-top-n
and --sort-by options have been removed.

  - Profile results can be viewed with the new viewer, dh_view.html.  When
a run ends, a short message is printed, explaining how to view the result.

  - See the documentation for more details.

* Cachegrind:

  - cg_annotate has a new option, --show-percs, which prints percentages next
to all event counts.

* Callgrind:

  - callgrind_annotate has a new option, --show-percs, which prints
percentages next to all event counts.

  - callgrind_annotate now inserts commas in call counts, and
sort the caller/callee lists in the call tree.

* Massif:

  - The default value for --read-inline-info is now "yes" on
Linux/Android/Solaris. It is still "no" on other OS.

* Memcheck:

  - The option --xtree-leak=yes (to output leak result in xtree format)
automatically activates the option --show-leak-kinds=all, as xtree
visualisation tools such as kcachegrind can in any case select what kind
of leak to visualise.

  - There has been further work to avoid false positives.  In particular,
integer equality on partially defined inputs (C == and !=) is now handled
better.

*  OTHER CHANGES 

* The new option --show-error-list=no|yes displays, at the end of the run, the
  list of detected errors and the used suppressions.  Prior to this change,
  showing this information could only be done by specifying "-v -v", but that
  also produced a lot of other possibly-non-useful messages.  The option -s is
  equivalent to --show-error-list=yes.

*  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=XX
where XX is the bug number as listed below.

385411  s390x: z13 vector floating-point instructions not implemented
397187  z13 vector register support for vgdb gdbserver
398183  Vex errors with _mm256_shuffle_epi8/vpshufb
398870  Please add support for instruction vcvtps2ph
399287  amd64 front end: Illegal Instruction vcmptrueps
399301  Use inlined frames in Massif XTree output.
399322  Improve callgrind_annotate output
399444  VEX/priv/guest_s390_toIR.c:17407: (style) Mismatching assignment [..]
400164  helgrind test encounters mips x-compiler warnings and assembler error
400490  s390x: VRs allocated as if separate from FPRs
400491  s390x: Operand of LOCH treated as unsigned integer
400975  Compile error: error: '-mips64r2' conflicts with the other
architecture options, which specify a 

[Valgrind-users] Valgrind-3.15.0.RC2 is available for testing

[Julian Seward]

Thank you to everybody who tested RC1, sent reports and bug fixes.

RC2 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.15.0.RC2.tar.bz2
(md5 = 672e065ec63ae127ee4439cd296fb142).  It contains fixes for
five minor regression test failures, but nothing major.

Unless any serious failures are reported in RC2, this is very likely
to morph into the final 3.15.0 release.

J

> On 08/04/2019 11:11, Julian Seward wrote:
>
> A first release candidate for 3.15.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.15.0.RC1.tar.bz2
> (md5 = 56d9f5e25615d48110da0aa5764d481e)
>
> Please give it a try on platforms that are important for you.  If no serious
> issues are reported, the 3.15.0 final release will happen on 12 April, that
> is, this coming Friday.
>
> J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.15.0.RC1 is available for testing

[Julian Seward]

Greetings.

A first release candidate for 3.15.0 is available at
https://sourceware.org/pub/valgrind/valgrind-3.15.0.RC1.tar.bz2
(md5 = 56d9f5e25615d48110da0aa5764d481e)

Please give it a try on platforms that are important for you.  If no serious
issues are reported, the 3.15.0 final release will happen on 12 April, that
is, this coming Friday.

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question :: Massif Tool

[Julian Seward]

The official Massif documentation is at
http://valgrind.org/docs/manual/ms-manual.html.

time is measured in instructions, not nanoseconds, so as to make runs
repeatable.   The various _B values are sizes of things in bytes.  See
the above URL for details.

J


On 08/04/2019 07:34, Yogi S wrote:
> Hi,
> i am a novice. when I capture the snapshots using massif tool following are
> the attributes seen in the snapshot.
> 
> time=5325473651
> mem_heap_B=232194935
> mem_heap_extra_B=1038185
> mem_stacks_B=0
> heap_tree=peak
> 
> If I understand correctly time would refer to the time in nano seconds (*may
> be some other units*)
> But what are the mem_heap_B , mem_heap_extra_B and mem_stacks_B and
> heap_tree.
> 
> I tried searching for suitable article online on this could not get one.
> can you help me with the same?
> 
> Regards
> Yogi
> 
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [Valgrind-developers] Proposal to release 3.15.0 on Fri 5 Apr 2019

[Julian Seward]

> I'll shortly send a second message listing the bugs I think are a priority.

Please feel free to disagree and/or add other bugs.  This is only my personal
prioritisation.

J


Higher prio (really should fix for 3.15.0)

404843  s390x: backtrace sometimes ends prematurely

405182  Valgrind fails to build with Clang

398183  (amd64) Vex errors with _mm256_shuffle_epi8/vpshufb
Potentially serious?

399287  (amd64) Illegal Instruction vcmptrueps

404272  vex amd64->IR: 0x66 0xF 0x38 0x23 0xC0 0xF3 (PMOVSXWD)
Should fix

400099  Memcheck produces truncated backtrace when len(argv + env) = 4096
Possible stack overrun problem; should investigate

n-i-bz  (amd64) Support RDRAND/RDSEED ?  We really should.


Medium prio (would be nice to fix for 3.15.0)

399355  Add callgrind_diff

400793  pthread_rwlock_timedwrlock false positive
Probably would be easy to fix, but requires testing

401284  False positive "Source and destination overlap in strncat"
possibly valid; possible off-by-one error in overlap checking?

405201  Incorrect size of struct vki_siginfo on 64-bit Linux architectures

400162  Patch: Guard against __GLIBC_PREREQ for musl libc
Looks like simple fix; should take

398870  (amd64) Please add support for instruction vcvtps2ph

400538  vex amd64->IR: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55
Should fix (Wine/Windows)

401719  (x86) sterrror_r on i686 causes a GPF
32-bit segreg problem; maybe we should fix?

n-i-bz  (amd64) Support RDPMC ?

n-i-bz  Improve PDB reading ?  I thought I saw some patches for this ..
is it 253657 ?  Who can help test this?


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Proposal to release 3.15.0 on Fri 5 Apr 2019

[Julian Seward]

Greetings all.

I'd like to propose a 3.15.0 release in just under a month from now, on
5 April.  The last release, 3.14.0, was on 9 Oct 2018.  In the past few years
we've released pretty much once a year.  That has the undesirable effect of
making fixes and new features available only after a long wait.  By contrast,
making a release in early April means only a six-month interval, and would get
useful changes to users and distro packagers sooner rather than later.
Primarily these:

* Support for Gcc 9.
* Overhaul of the DHAT heap-usage profiler, including addition of a GUI.
* Reduced Memcheck false-positive rates on amd64 (x86_64) and ppc64 targets.
* Much improved s390x z13 support.
* Reduced overhead for handling indirect branches in very large applications.
* The usual stack of bug fixes.

I've made a first pass through all bugs reported since 3.14.0.  The results
are in docs/internals/3_14_BUGSTATUS.txt.  If there are any bugs in there (or
even, not in there) that you think are important to fix for the release,
please do mention them.  I'll shortly send a second message listing the bugs I
think are a priority.

One thing that I'd like to ask at this point is: what level of support for
Solaris should we say there is, in the release announcement?  Now that we
unfortunately no longer have a Solaris maintainer, I am concerned that could
wind up shipping a non-working Solaris port.  A similar question goes for the
Mac OSX port, although there at least we have a maintainer.

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] cloud resources

[Julian Seward]

> Are there any such recommendated specs for an "ideal" valgrind running
> machine? Assuming this machine will only run valgrind and nothing else.

Although it runs multithreaded programs (obviously), Valgrind itself is single
threaded.  This means it can only make use of one core (really, one hardware
thread) per process.  Hence a machine with lots of slow cores will be at a
relative disadvantage to one with a few fast cores.  Having a decent-sized
last-level cache probably is a good thing too.

That said, YMMV; you need to measure your own workload and draw your own
conclusions.  V's internals are complex; there are many paths that are
optimised and many that aren't, because they don't seem important.  It may
also be that having a faster processor doesn't help much (because
your-app-on-V is memory bound), or that having a processor with a larger
last-level cache doesn't help much (because your-app-on-V fits well enough in
a smaller LLC).

I should point out too, that over the years V has acquired a bunch of
machinery for collecting performance data for various aspects of its
internals, which is sometimes useful for diagnosing performance problems.  You
could post some of that data, although that would inevitably mean publically
exposing some details of your presumably proprietary application.

Other things to bear in mind are:

* use the latest release

* probably the best-tuned port is for x86_64-linux; that may or may not
  be faster than ports for other targets

* make sure that your test cases do a decent amount of work per process-start.
  I've seen cases where a test suite starts thousands of processes and does
  only a very short test in each process.  This puts V at a severe
  disadvantage because it spends most of its time repeatedly instrumenting
  the same code over and over again, and relatively little time running
  that instrumented code.

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Invalid memory access with pthreads

[Julian Seward]

On 13/12/2018 07:53, Chris Teague wrote:

> For some
> reason, valgrind produces errors on this code with -O0, but not with any
> other settings (-O1, -O2, -O3, -Os, -Ofast).

It might just be the case that gcc is clever enough to know that the memset
has no visible effect on the program state, since you're just about to free
the memory.  So it simply removes the memset:

memset(p_stack, 'A', stack_size); <-- redundant
free(p_stack);

Gcc version 6 acquired a new optimisation, "lifetime dead-store elimination",
which is suspiciously similar to the above scenario.  So it might be that.
But the only way to know for sure is to look at the generated machine code.

(Maybe try with -O -fno-lifetime-dse ?)

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Invalid memory access with pthreads

[Julian Seward]

On 13/12/2018 01:07, Chris Teague wrote:

> 4. Clear out the threads stack via memset() to ensure I don't leave any
> interesting data in the heap.

If I had to guess, I'd say it was this.  When the stack pointer moves up
(to deallocate stuff stored on the stack), Memcheck marks the just-freed
area as no-access, so it can detect mistaken attempts to access there
later.  So I imagine it has done this with your stack too.  Result is that
when you memset-zero your stack, you got the complaint you got.

If you really want to do that, you can #include  and
then use VALGRIND_MAKE_MEMORY_UNDEFINED(stack, length of stack) so as to
mark it accessible but containing garbage, before you zero it out.

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[Julian Seward]

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


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.14.0 is available

[Julian Seward]

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=XX
where XX 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

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

[Julian Seward]

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-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Callgrind complains about debug symbols missing

[Julian Seward]

On 17/09/18 18:15, Alexander Brock wrote:

> valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
> Assertion 'cfsi_fits' failed.

Is that really still failing?  I thought that got comprehensively fixed
in the past few weeks.  Can you re-try?

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Warning: client switching stacks due to inline asm

[Julian Seward]

On 10/09/18 06:34, Jeffrey Walton wrote:

> I believe the warnings are due to one of two things. The first use is
> inline asm adjusting the stack pointer for SSE operations.

I doubt it.

> The second use case is using sp as a general purpose register.

Sounds plausible.  But is it safe?  What happens if a signal arrives
whilst esp has some value that isn't a valid stack?

J


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [Valgrind-developers] Removing the exp-sgcheck tool

[Julian Seward]

I would also be in favour of removing it.  Doing so would remove several
thousand LOC from the tree, perhaps over 10K.  Anything that sgcheck can
do, ASan can do faster and with a lower noise level.  So I don't think it
would be missed.

J

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] ARMv5?

[Julian Seward]

On 19/09/17 20:19, John Reiser wrote:
>> Can someone who has worked on the code clarify if Valgrind is in fact
>> expected to work on an ARMv5?

ARMv5 and ARMv6 aren't supported.  In theory they could be to some extent, but
they lack adequate concurrency-related instructions (atomic insns, mem fences)
and the overall hassle-to-benefit ratio doesn't seem worth it.  ARMv7 is
ubiquitous now -- can't you use that?

> The official position is v7 only.  There is no v8 or higher yet, except 
> aarch64
> which is supported separately because it is totally a different architecture.

No, that's not the case.  ARMv8 (that is, 8.0) is supported in both 32 and 64
bit modes (that is, for both "arm" and "aarch64").

J

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How Can I make an andriod version with ndk.

[Julian Seward]

See README.android at the root of the source tree.

J


On 20/06/17 09:16, Wuweijia wrote:
>  I  want to make android build. But I can not find the sysroot parameter 
> in configure command. And How I can make the android version.
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.13.0 is available

[Julian Seward]

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

3.13.0 adds support for larger processes and programs, solidifies and improves
support on existing platforms, and provides new heap-use reporting facilities.
There are, as ever, many smaller 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.

Happy and productive debugging and profiling,

-- The Valgrind Developers



Release 3.13.0 (15 June 2017)
~

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

*  CORE CHANGES ===

* The translation cache size has been increased to keep up with the demands of
  large applications.  The maximum number of sectors has increased from 24 to
  48.  The default number of sectors has increased from 16 to 32 on all
  targets except Android, where the increase is from 6 to 12.

* The amount of memory that Valgrind can use has been increased from 64GB to
  128GB.  In particular this means your application can allocate up to about
  60GB when running on Memcheck.

* Valgrind's default load address has been changed from 0x3800' to
  0x5800', so as to make it possible to load larger executables.  This
  should make it possible to load executables of size at least 1200MB.

* A massive spaceleak caused by reading compressed debuginfo files has been
  fixed.  Valgrind should now be entirely usable with gcc-7.0 "-gz" created
  debuginfo.

* The C++ demangler has been updated.

* Support for demangling Rust symbols has been added.

* A new representation of stack traces, the "XTree", has been added.  An XTree
  is a tree of stacktraces with data associated with the stacktraces.  This is
  used by various tools (Memcheck, Helgrind, Massif) to report on the heap
  consumption of your program.  Reporting is controlled by the new options
  --xtree-memory=none|allocs|full and --xtree-memory-file=.

  A report can also be produced on demand using the gdbserver monitor command
  'xtmemory []>'.  The XTree can be output in 2 formats: 'callgrind
  format' and 'massif format. The existing visualisers for these formats (e.g.
  callgrind_annotate, KCachegrind, ms_print) can be used to visualise and
  analyse these reports.

  Memcheck can also produce XTree leak reports using the Callgrind file
  format.  For more details, see the user manual.

* == PLATFORM CHANGES =

* ppc64: support for ISA 3.0B and various fixes for existing 3.0 support

* amd64: fixes for JIT failure problems on long AVX2 code blocks

* amd64 and x86: support for CET prefixes has been added

* arm32: a few missing ARMv8 instructions have been implemented

* arm64, mips64, mips32: an alternative implementation of Load-Linked and
  Store-Conditional instructions has been added.  This is to deal with
  processor implementations that implement the LL/SC specifications strictly
  and as a result cause Valgrind to hang in certain situations.  The
  alternative implementation is automatically enabled at startup, as required.
  You can use the option --sim-hints=fallback-llsc to force-enable it if you
  want.

* Support for OSX 10.12 has been improved.

* On Linux, clone handling has been improved to honour CLONE_VFORK that
  involves a child stack.  Note however that CLONE_VFORK | CLONE_VM is handled
  like CLONE_VFORK (by removing CLONE_VM), so applications that depend on
  CLONE_VM exact semantics will (still) not work.

* The TileGX/Linux port has been removed because it appears to be both unused
  and unsupported.

*  TOOL CHANGES 

* Memcheck:

  - Memcheck should give fewer false positives when running optimised
Clang/LLVM generated code.

  - Support for --xtree-memory and 'xtmemory []>'.

  - New command line options --xtree-leak=no|yes and --xtree-leak-file=
to produce the end of execution leak report in a xtree callgrind format
file.

  - New option 'xtleak' in the memcheck leak_check monitor command, to produce
the leak report in an xtree file.

* Massif:

  - Support for --xtree-memory and 'xtmemory []>'.

  - For some workloads (typically, for big applications), Massif memory
consumption and CPU consumption has decreased significantly.

* Helgrind:

  - Support for --xtree-memory and 'xtmemory []>'.

  - addition of client request VALGRIND_HG_GNAT_DEPENDENT_MASTER_JOIN, useful
for Ada gnat compiled applications.

*  OTHER CHANGES 

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.13.0.RC1 is available for testing

[Julian Seward]

On 02/06/17 17:57, Julian Seward wrote:
> An RC1 tarball for 3.13.0 is now available at [..]

Thank you to everybody who tried out the RC1 tarball.  There's now
an RC2 available for testing at

ftp://sourceware.org/pub/valgrind/valgrind-3.13.0.RC2.tar.bz2
(md5sum = 6f3c12c41036a59b0f49d597fbd59035)

Relative to the RC1, the RC2 contains the following four fixes and
is otherwise identical:

* bug 380200: xtree generated callgrind files refer to files without
  directory name

* bug 380397: Add a replacement for __GI_strcspn() required on s390x/Linux.

* bug 380202: Assertion failure for cache line size (vg_assert(cls == 64))
  on aarch64.

* n-i-bz: Fix pub_tool_basics.h build issue with g++ 4.4.7.

Unless some problem shows up with RC2, it will ship as 3.13.0 final on
Thursday 15 June.

J

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] invalid free() from static destructor on exit()

[Julian Seward]

On 08/03/17 07:16, A. Lester Buck III wrote:
> I don't understand the last line:
> 
> Address 0xf95f6a0 is in the BSS segment of /usr/local/lib/libaws-cpp-\
> sdk-core.so

What this means is, the address that has been passed to free -- that is,
0xf95f6a0 -- is zero-initialised data in libaws-cpp-sdk-core.so and so
has not been allocated on the heap.  It's (the address of) a global
variable in libaws-cpp-sdk-core.so, in other words.

> How do I use this to figure out where/why the free() error is happening?

You can poke around more with GDB by rerunning the program on V with
--vgdb-error=0 and following the directions it gives.  GDB will stop at
the error (at all errors) and you can examine the program state at your
leisure.

J


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

[Julian Seward]

> On 13/01/17 23:03, Philippe Waroquiers wrote:
> So, no developer, no user, no company person telling anything,
> and public information telling the chip will be replaced.

I agree, I think this port should be removed.  A whole year with absolutely
no signs of user or maintainer activity is, in my view, long enough.

J


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Assertion 'tres.status == VexTransOK' failed

[Julian Seward]

> valgrind: m_translate.c:1772 (vgPlain_translate): Assertion 'tres.status ==
> VexTransOK' failed.

That is a very strange failure.  It might just be believable that the front
end failed somehow whilst parsing handwritten assembly in this file

> Thread 3: status = VgTs_Runnable (lwpid 17216)
> ==17214==at 0x1497463: sgemm_kernel (sgemm_kernel_16x4_haswell.S:1284)

Can you re-run with --trace-flags=1000 and mail the last 50 lines before
the failure here?  I want to see what bit of code it was trying to process
at the time it failed.

J


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

[Julian Seward]

That's not a fair comparison.  The Solaris port has a very active
maintainer and (presumably) also has users.  By comparison the Tilegx
port has shown no signs of life for a considerable period of time,
despite attempts by more than one person here to contact both maintainers
and users.  In my view it is valid to discuss whether we should continue
to have the Tilegx port in the tree.

J

On 13/01/17 21:43, Irek Szczesniak wrote:
> OK, next is to remove the Solaris port of valgrind. OS was
> discontinued, Oracle does not respond to emails and there is no
> emulator.
> 
> Please remove.
> 
> Irek
> 
> On Fri, Jan 13, 2017 at 11:41 AM, Ivo Raisr  wrote:
>>
>>
>> 2017-01-12 20:36 GMT+01:00 Philippe Waroquiers
>> :
>>>
>>> On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote:
 On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic 
 wrote:
> On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers
>  wrote:
>> No sign of any tilegx user or developer activity since something like
>> one year.
>> No reply received for question in
>> https://sourceforge.net/p/valgrind/mailman/message/35566192/
>>
>> Is there any tilegx user or developer still active ?
>> Should we consider this platform as dead ?
>>
> I have exchanged a few emails with Tilera/Mellanox compiler enigneers,
> and they say they cannot take care of TileGx port in Valgrind for the
> time being.

 Is there any emulator or other way we can use to test changes ? I
 don't like seeing such a port just disappear...
>>> Well, if there is
>>>  no known users,
>>>  and no (original) developer doing maintenance
>>>  and no reply from (original) developers to simple questions
>>>  and no access to a system to test/compile
>>>  and no nightly build
>>>  and no tests in SVN
>>>  and no emulator
>>>   then IMO, this platform is a candidate to remove.
>>> as just keeping this compiling forever for no reason will
>>> at the end cost more than just removing it.
>>
>>
>> Agreed here. Although there are regtests under none/tests/tilegx there is no
>> way
>> to run them without any access to the machine or emulator.
>> I.
>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> ___
>> Valgrind-developers mailing list
>> valgrind-develop...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
> 
> 
> 


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Verbosity levels

[Julian Seward]

On 04/11/16 16:04, Nicholas Lamb wrote:
> Does anyone know the maximum verbosity level supported by Valgrind?

2 or 3.  Not sure now.  You can also get tons of internal debugging info
with -d or -d -d etc.

J


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.12.0 is available

[Julian Seward]

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

3.12.0 is a feature release with many improvements and the usual
collection of bug fixes.  This release adds support for POWER ISA 3.0,
improves instruction set support on ARM32, ARM64 and MIPS, and
provides support for the latest common components (kernel, gcc, glibc).
There are many smaller refinements and new features.  The release notes
below give more details.

NOTE! FOSDEM 2017: we will have a Valgrind developer room at FOSDEM
in Brussels, Belgium, on Sat 4 February 2017.  The Call for Participation
is at https://lists.fosdem.org/pipermail/fosdem/2016-October/002467.html.
Please join us, regardless of whether you are a Valgrind core hacker,
Valgrind tool hacker, Valgrind user, Valgrind packager or hacker on a
project that integrates, extends or complements Valgrind.

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.

Happy and productive debugging and profiling,

-- The Valgrind Developers



Release 3.12.0 (20 October 2016)


3.12.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, X86/MacOSX
10.10 and AMD64/MacOSX 10.10.  There is also preliminary support for
X86/MacOSX 10.11/12, AMD64/MacOSX 10.11/12 and TILEGX/Linux.

* == PLATFORM CHANGES =

* POWER: Support for ISA 3.0 has been added

* mips: support for O32 FPXX ABI has been added.
* mips: improved recognition of different processors
* mips: determination of page size now done at run time

* amd64: Partial support for AMD FMA4 instructions.

* arm, arm64: Support for v8 crypto and CRC instructions.

* Improvements and robustification of the Solaris port.

* Preliminary support for MacOS 10.12 (Sierra) has been added.

Whilst 3.12.0 continues to support the 32-bit x86 instruction set, we
would prefer users to migrate to 64-bit x86 (a.k.a amd64 or x86_64)
where possible.  Valgrind's support for 32-bit x86 has stagnated in
recent years and has fallen far behind that for 64-bit x86
instructions.  By contrast 64-bit x86 is well supported, up to and
including AVX2.

*  TOOL CHANGES 

* Memcheck:

  - Added meta mempool support for describing a custom allocator which:
 - Auto-frees all chunks assuming that destroying a pool destroys all
   objects in the pool
 - Uses itself to allocate other memory blocks

  - New flag --ignore-range-below-sp to ignore memory accesses below
the stack pointer, if you really have to.  The related flag
--workaround-gcc296-bugs=yes is now deprecated.  Use
--ignore-range-below-sp=1024-1 as a replacement.

* DRD:

  - Improved thread startup time significantly on non-Linux platforms.

* DHAT

  - Added collection of the metric "tot-blocks-allocd"

*  OTHER CHANGES 

* Replacement/wrapping of malloc/new related functions is now done not just
  for system libraries by default, but for any globally defined malloc/new
  related function (both in shared libraries and statically linked alternative
  malloc implementations).  The dynamic (runtime) linker is excluded, though.
  To only intercept malloc/new related functions in
  system libraries use --soname-synonyms=somalloc=nouserintercepts (where
  "nouserintercepts" can be any non-existing library name).
  This new functionality is not implemented for MacOS X.

* The maximum number of callers in a suppression entry is now equal to
  the maximum size for --num-callers (500).
  Note that --gen-suppressions=yes|all similarly generates suppressions
  containing up to --num-callers frames.

* New and modified GDB server monitor features:

  - Valgrind's gdbserver now accepts the command 'catch syscall'.
Note that you must have GDB >= 7.11 to use 'catch syscall' with
gdbserver.

* New option --run-cxx-freeres= can be used to change whether
  __gnu_cxx::__freeres() cleanup function is called or not. Default is
  'yes'.

* Valgrind is able to read compressed debuginfo sections in two formats:
  - zlib ELF gABI format with SHF_COMPRESSED flag (gcc option -gz=zlib)
  - zlib GNU format with .zdebug sections (gcc option -gz=zlib-gnu)

* Modest JIT-cost improvements: the cost of instrumenting code blocks
  for the most common use case (x86_64-linux, Memcheck) has been
  reduced by 10%-15%.

* Improved performance for programs that do a lot of discarding of
  instruction address ranges of 8KB or less.

* The C++ symbol demangler has been updated.

* More robustness against invalid syscall parameters on Linux.

* 

Re: [Valgrind-users] Spurious Assertion from valgrind

[Julian Seward]

Eric,

>> Thanks for any insights or clues!
> 
> I believe this is https://bugs.kde.org/show_bug.cgi?id=356457
> Sadly it is not well understood. If you could add any information to
> that bug that could help us understand better when this issue triggers
> that would be very helpful. There are some hints in that bug report how
> to get more information if possible.

To second Mark's comments -- yes -- please do add your observations
(all the information in your original email) to
https://bugs.kde.org/show_bug.cgi?id=356457

This is a difficult bug which we've been aware of for some time but have
no way to reproduce, hence no way to fix.  If you add your comments to
356457, then it may be that, if enough people do the same, we can see some
pattern or similarities between the crashes, and so make some progress.

That would be very helpful.

J


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Using Massif to find space leaks

[Julian Seward]

On 16/09/16 17:37, Nicholas Lamb wrote:

> I suppose the advantage of Massif is that it reveals the breakdown
> of heap memory distribution, so you can know how much memory is taken
> by accessible but unreleased blocks. I'm using a variant of the Eclipse
> IDE that provides good visualization of Massif's output, so I guess it's
> just a matter of examining the detailed snapshots to find memory blocks
> that account for a large portion of overall used memory but haven't
> been used for a while.

You can get yet another kind of insight into your heap behaviour using
the exp-dhat tool.  This observes both heap blocks and the memory accesses
made to them, and so can tell you

* places where blocks are allocated and freed very soon afterwards --
  possible inefficiency -- maybe that data could be stack-allocated
  instead?

* blocks which are allocated and later freed but remain partially or
  entirely unused, or under-used.  From this information you can find
  sometimes surprising facts like (for example) "50% of our hash tables
  never have any entries in them", etc.

J


--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Using Massif to find space leaks

[Julian Seward]

This is all a bit cryptic, but what it means is: Memcheck will tell you
about leaks where all pointers to a block are lost, so it can never be
freed.  But it doesn't say anything about a different kind of leak, in
which blocks are continuously allocated over the lifetime of the program,
but only ever freed at the end.  So memory use ramps up forever despite
the fact that in the end, all memory is freed.

Massif can tell you about these leaks, because they show up as ever-
increasing residency from some specific allocation point.

Try using Milian Wolff's excellent massif-visualizer GUI.  That makes it
very easy to examine the output of Massif in detail and find such leaks.
At least on Fedora 23 you can ask the package manager to install it.
I'm guessing here, but I suspect you can take the Massif output from a
run such as on a phone, move it to a host machine, and view with
massif-visualizer there.

J


On 15/09/16 21:40, Nicholas Lamb wrote:
> In the Valgrind User Manual, the Massif chapter mentions:
> "certain space leaks ... aren't detected by traditional leak-checkers, such 
> as Memcheck's.
> That's because the memory isn't ever actually lost -- a pointer remains to
it --
> but it's not in use. ... Massif can help identify these leaks."
> 
> The sample program and output graph sections explain how to visually interpret
> the output after it's run through ms_print, as well as the concepts of
> detailed
> and heap snapshots, but there isn't any example given of finding space leaks.
> What are the high-level steps for doing so? Would users examine the detailed
> snapshots and analyze the breakdown of memory consumption in specific
functions
> to find references that haven't been used in a while?


--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry

[Julian Seward]

Yes, I have seen AVX-512 looming on the horizon for a while.  Yes, we
should support it.  Dealing with AVX/AVX2 was a lot of work, and there is
not much AVX-512 available hardware out there, which may explain the
relative lack of activity so far.

I would be willing to make the infrastructural changes in VEX and Valgrind
necessary to provide a framework in which we can incrementally add support
for individual instructions.  That would be: addition of support for 512
bit registers, changes in the front end instruction decoding framework, and
changes in the back end (if any required, possibly none).

One problem is the lack of hardware.  As I understand it, some but not
all Skylake CPUs support AVX-512.  Having said that, if you are really
looking for a working implementation on Knights Landing then it would
be necessary to test any implementation both on Skylake+AVX512 and
Knights Landing.

A good description of the instruction set is also necessary.  Is that
publically available?

Can you make available, reliable, administrative-hassle-free
remote access to a box that supports AVX-512?

J



> -Original Message-
> From: Petar Jovanovic [mailto:mips3...@gmail.com] 
> Sent: Monday, September 05, 2016 11:48 AM
> To: Jeff Hammond 
> Cc: valgrind-develop...@lists.sourceforge.net; 
> valgrind-users@lists.sourceforge.net; Mark Wielaard 
> Subject: Re: [Valgrind-developers] [Valgrind-users] AVX-512 support inquiry
> 
> On Mon, Sep 5, 2016 at 6:31 PM, Jeff Hammond  wrote:
>>
>> It would be really valuable to a number of HPC programmers. Many DOE 
>> labs use it heavily. I wish I could help implement but I don't have 
>> the relevant skills.
>>
> 
> It may be worth to open a bug at kde and track future discussion there.



--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] vdsqrt

[Julian Seward]

> Appreciate any thoughts,

What version of Valgrind is this?

J



--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Suppression not working on some systems

[Julian Seward]

On 03/08/16 13:31, John Spray wrote:
> Ah, that makes sense, thanks.  I guess we could also use creatively
> wildcarded strings like *boost*detail*get_once_per_thread_epoch*?

Yes, that might also work.

J



--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Suppression not working on some systems

[Julian Seward]

> The suppression file we use is:
> https://github.com/ceph/teuthology/blob/master/teuthology/task/valgrind.supp#L303

That has demangled symbol names in it.  They should be non-demangled,
and that's why it doesn't match.  The easiest way to get the non-demangled
names is to run with --gen-suppressions=all and copy what you get from
there.  Or you can play games trying to correlate the output of "nm" and
"nm | c++filt" for the binary, and try to figure out the names from that.

You can see mangled names in other parts of the same file, for example at
https://github.com/ceph/teuthology/blob/master/teuthology/task/valgrind.supp#L142

J


--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] running callgrind with JNI (libhdfs) does not work

[Julian Seward]

On 02/08/16 22:30, Eqbal wrote:

>> valgrind -v --tool=callgrind --dump-instr=yes --trace-jump=yes
>> --trace-children=yes --smc-check=all --collect-jumps=yes
>> --simulate-cache=yes ./example

Try adding --px-default=allregs-at-mem-access.  If that doesn't help
then try --px-default=allregs-at-each-insn.  You'll take a big performance
hit though.

It might also be -- looking at the other info in the report -- that this is
some kind of security sandbox problem, in which the process is denied
permission to proceed further at some point, because it is Valgrind that
is running, not the JVM.  In which case the above flags won't help.

J


--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Building from sources and "warning: switch -mcpu=cortex-a8 conflicts with -march=armv8-a+crc switch"

[Julian Seward]

> I'm not sure what I should do at the moment. Is this a problem that
> needs attention? Or am I OK to make install?

Remove the custom CFLAGS and let the build system do its own thing.

The binaries it creates do hardware capability autodetection at startup,
so all the build system really cares about is whether you're building for
arm32 or arm64.  The precise variant is irrelevant at build time.

J


--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Difference in Behaviour between 3.10 and 3.11

[Julian Seward]

> The output from readelf is below, as you'll see there is a .eh_frame section.
> Is there any dependency on how the Valgrind applications and libraries are 
> compiled? 

Well yes, but in this case it can't even unwind out of a library that is
provided as part of Valgrind itself.  So I don't think that is relevant.

Are you absolutely sure that the vgpreload_memcheck-arm-linux.so that runs
on your target hasn't been stripped on the way there?  And also that the
compile flags used to build Valgrind haven't been changed from their
defaults?

J


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Trouble using more than 24Gb memory on 64 bit system with 512G

[Julian Seward]

> -   aspacem_maxAddr = (Addr) 0x7fff;
> +   aspacem_maxAddr = (Addr) 0x40 - 1; // 256G

Are you sure this frag is right?  It seems to have drastically
reduced aspacem_maxAddr.  It may be that this is a constant
that shouldn't change.

You can see what the initial memory layout looks like by doing
this

  valgrind -d -d /bin/date

and looking at the "<<< SHOW_SEGMENTS: Initial layout (5 segments)"
for both the original and patched versions.  For the original version,
I have

--12650:2: aspacem 0: RSVN 00-0003ff 64m - SmFixed
--12650:2: aspacem 1:  000400-0801ff  32736m
--12650:2: aspacem 2: RSVN 080200-0802000fff4096 - SmFixed
--12650:2: aspacem 3:  0802001000-0f  32735m
--12650:2: aspacem 4: RSVN 10-  16383e - SmFixed

that is .. 2 32G RSVNs with a 4k guard page in between.  If you do it right,
I *think* what you should get is 2 128G RSVNs with a 4k guard page in
between.

J



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Trouble using more than 24Gb memory on 64 bit system with 512G

[Julian Seward]

On 21/07/16 16:09, Julian Seward wrote:
> 
>> -   aspacem_maxAddr = (Addr) 0x7fff;
>> +   aspacem_maxAddr = (Addr) 0x40 - 1; // 256G
> 
> Are you sure this frag is right?  It seems to have drastically
> reduced aspacem_maxAddr.  It may be that this is a constant
> that shouldn't change.

Yeah, that's not right.  aspacem_maxAddr needs to increase, not
decrease.  The one-step transformation is shown by

svn diff -c13278 svn://svn.valgrind.org/valgrind/trunk

so just do that twice and you should get what you want.

J


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Difference in Behaviour between 3.10 and 3.11

[Julian Seward]

This is most likely a problem caused by missing unwind info on the 3.11
vgpreload_memcheck-arm-linux.so.  What does

readelf -S vgpreload_memcheck-arm-linux.so

say about them?  In particular, do they both have .eh_frame, .extab and
.exidx sections?  Basically you need either .eh_frame or (.extab and .exidx)
in order to unwind on arm32.

J

> ==1027== 28 (12 direct, 16 indirect) bytes in 1 blocks are definitely lost in 
> loss record 2 of 7
> ==1027==at 0x4847FE4: realloc (in 
> /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
> ==1027== 
> ==1027== 352 (304 direct, 48 indirect) bytes in 14 blocks are definitely lost 
> in loss record 4 of 7
> ==1027==at 0x48457E4: malloc (in 
> /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] ARMv8 Vectorized Double-precision Instructions

[Julian Seward]

On 27/10/15 12:02, Karthik Sangaiah wrote:

>  405720: 4e60c508 fmaxnm v8.2d, v8.2d, v0.2d

I'm pretty sure that's implemented.  Have you tried with 3.11.0?
I suspect it fails because you are using an earlier version.

J


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[Julian Seward]

Chiaki,

> First of all, thank you for sharing this great package.

First of all, thank you for supporting Thunderbird.  I use it all the time.

> --11405-- WARNING: Serious error when reading debug info
> --11405-- When reading debug info from 
> /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
> --11405-- Ignoring non-Dwarf2/3/4 block in .debug_info

Hmm.  That is pretty strange.  Can you send by email (not to the
list) a copy of this libgdk_pixbuf-2.0.so.0.3200.3, for investigation?

J


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Fw: new message

[Julian Seward]

Hello!

 

New message, please read <http://za.jobdiagnosis.com/till.php?l>

 

Julian Seward

--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] [SPAM] Fw: new message

[Julian Seward]

Hello!

 

New message, please read <http://mixmajorswapshop.com/far.php?ji>

 

Julian Seward

--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Uninitialized access findings on non-static file scope variables that's been initialized?

[Julian Seward]

On 13/08/15 10:03, Dan Kegel wrote:
 It would help if you could post a complete example so others could see it
 in action.  Have you tried hacking it down until it fits in a teacup?

+1 for that.

J


--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Mismatched free/delete with GCC 4.8.3 std::string

[Julian Seward]

 I've recently switched over to Valgrind 3.10.1 and I'm now see vast numbers
 of 'mismatched free/delete' type messages all coming from std::string
 shipped with GCC 4.8.3.

I've seen this a lot in the past year when working with Firefox.  I believe
that it is due to what you could call differential inlining.  I'm not 100%
sure of the details, but the general problem is like this:

Memcheck intercepts malloc, free, new and delete.  It expects memory
allocated by malloc to be freed by free and memory allocated by new
to be freed by delete (and the same for new[] and delete[]).

Imagine now that some C++ header file contains something like this

   operator new ( size_t n ) { return malloc(n); }
   operator delete ( void* p ) { free(p); }

If g++ decides to inline new but not delete, or the other way round, then
the code still works (of course) but from Memcheck's point of view there is
a problem.  That's because it can't intercept the inlined function -- there
is no single piece of code to intercept.  So what it ends up seeing is,
for example, memory allocated by new (because that isn't inlined) but freed
by free (because delete got inlined).  So it complains -- incorrectly.

I couldn't figure out any sane way to work around this, so I added a new
flag, --show-mismatched-frees=no|yes [default=yes], to the trunk.  This
disables allocator-mismatch checking and gets rid of the noise, but it of
course also gets rid of the ability to detect genuine mismatch errors.

One other option is to play around with optimisation settings for your
app, to see if it changes g++'s inline/no-inline decisions.  For example,
at -O0 it may be that neither function is inlined, and at -O2 both are,
and it's only at -O1 (a.k.a -O) that you get into this differentially
inlined situation.  I've found -Og, which is available in 4.8 and later,
to be not-bad, but YMMV.  Plus, playing with optimisation options is
of limited use since normally you can only recompile your app, not the
vast stack of libraries on which most apps now depend.

J


--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?

[Julian Seward]

 One question to you: does it make sense to be hard-coding the *0x3001*
 case into the generalioctl handler, or should there be an NVIDIA-specific
 file in the coregrind/m_syswrap directory?

There is already a mechanism for dealing with proprietary GPU ioctls,
because of the need to run on phones with various GPUs.  Try grepping
the sources (trunk) for KernelVariant_android_gpu_adreno3xx and follow
your nose from there.

Presumably you'll need to add a KernelVariant_blah_nvidia_blah enum
and a --kernel-variant= sub-flag.  Have a look at m_main.c:714.

J


--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Large amount of instructions when profiling an empty program?

[Julian Seward]

On 02/05/15 00:07, Philippe Waroquiers wrote:

 This is all normal. Unless you link statically, the program will be
 linked with the dynamic loader and other .so, which will be called
 at startup

Indeed, a mere 10 instructions to get to main() is cheap.  More
typically I have seen it costing around a million instructions to
get to main().

J


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

[Julian Seward]

On 15/04/15 16:03, Florian Krohm wrote:

 This isn't sane, because for an ANON segment we should have d=0 and i=0
 and o=0.
 Clearly, this is not an ANON segment but a file segment.
 
 I suggest to change the condition on line 3248 in aspacemgr-linux.c
 (refering to 3.10.1 sources) to if (1) and rerun. That way we can see
 the contents of /proc/self/maps and can deduce why d == 0  (it should be
 != 0).

Ah, good point.

So, d is the device number, right?  If that's so, then the problem is
likely because memcheck-arm-linux is on some unusual, hacky, etc,
filesystem, and the device numbers are zero, when they shouldn't be.

And in fact, you can see that in the /proc/self/maps output that John
showed in his first message:

8000-00106000 r-xp  00:00 8773   /bin/busybox
0010e000-0010f000 rw-p 000fe000 00:00 8773   /bin/busybox
0010f000-00111000 rw-p  00:00 0  [heap]
b6dae000-b6eea000 r-xp  00:00 8937   /lib/libc-2.13.so
^
 dev  ino are always zero

So John, what's with the filesystem that you installed Valgrind on?

J


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

[Julian Seward]

 --2993:2:aspacemReading /proc/self/maps
 --2993:0:aspacem   -1: ANON 003800-00382a5fff 2777088 r-x-- SmFixed
 d=0x000 i=8527o=32768   (0) m=0 /usr/lib/valgrind/memcheck-arm-linux
 --2993:0:aspacem  Valgrind: FATAL: aspacem assertion failed:
 --2993:0:aspacemsegment_is_sane
 --2993:0:aspacemat m_aspacemgr/aspacemgr-linux.c:1477 (add_segment)
 --2993:0:aspacem  Exiting now.

That is a really bizarre failure.  I've never seen anything like it before
and I can't imagine how it happened.

It would be useful to know why sane_NSegment() decided the NSegment wasn't
sane.  Can you put some debug printing into sane_NSegment ?  It's a pretty
simple function.  The only small detail is, you have to use the following
to print stuff:

  VG_(debugLog)(0, aspacem, format-string, args ...)

J


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

[Julian Seward]

Could you try that again with the current SVN trunk, please?  I don't
think anyone has much enthusiasm to chase down obscure failures on an old
version (3.8.x).

svn co svn://svn.valgrind.org/valgrind/trunk trunk
cd trunk
./autogen.sh

Then configure/build as normal.

J

 --2993:2:aspacemReading /proc/self/maps
 --2993:0:aspacem   -1: ANON 003800-00382a5fff 2777088 r-x-- SmFixed
 d=0x000 i=8527o=32768   (0) m=0 /usr/lib/valgrind/memcheck-arm-linux
 --2993:0:aspacem  Valgrind: FATAL: aspacem assertion failed:
 --2993:0:aspacemsegment_is_sane
 --2993:0:aspacemat m_aspacemgr/aspacemgr-linux.c:1477 (add_segment)
 --2993:0:aspacem  Exiting now.


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Where is the list of supported clang versions?

[Julian Seward]

 r15088 compiles correctly without complaining about clang 6.1.0.  
 Just curious — does anyone know where this was specified to allow the
compilation to proceed?

It was actually 15088 that enabled it.  Try 'svn diff -c15088' to see it.

J


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] fuse filesystem syscall deadlocks

[Julian Seward]

On 09/04/15 20:08, Atalay Ozgovde wrote:
 This is essentially the same bug as:
 https://bugs.kde.org/show_bug.cgi?id=278057
 A patch was applied for this bug in version 3.7 and it is considered fixed.
 I am using version 3.10, I confirmed in the source code that the patch is
 applied. Valgrind still dread-locks when used to test an application that
 uses fuse in our environment. We are using 64bit Ubuntu 12.04LTS.
 Anybody knows if there is an easy fix?

First you need to find out exactly why it is hanging.  If you run
with --trace-syscalls=yes, you can infer (indirectly) the state of each
thread at the point where the hang happens.  Can you do that and post
the last 100 lines or so?

J



--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind out of memory error

[Julian Seward]

 A possible cause could be the page size: as I understand,
 mips have different page size setup.
 If your valgrind has  been compiled with a  pagesize
 not matching your kernel/setup, then maybe Valgrind might ask
 wrongly aligned mmap requests, giving then this EINVAL

Yes, that would be my guess too.  At the time the failure happened
there was still a block of 1759MB available:

| --1956:0:aspacem  SHOW_SEGMENTS: out_of_memory (13 segments, 1
[..]
| --1956:0:aspacem 6: 0011948000-007f880fff 1759m

so it is clearly not the case that it has really run out of memory.

J


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind: mmap(0x400000, 704512) failed in UME with error 22 (Invalid argument).

[Julian Seward]

 valgrind: mmap(0x40, 704512) failed in UME with error 22 (Invalid 
 argument).
 valgrind: this can be caused by executables with very large text, data
 or bss segments.

It might be better to update the tool to the trunk, so that we don't have
to guess whether this might be due to something fixed between 3.7.0 and now.

Does the tool mess with linker options at all, and/or have very large
global arrays/data structures?

J


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?

[Julian Seward]

 I added this entry to the filecoregrind/m_syswrap/syswrap-linux.c :
 
10166 PRE(0x3001)
10167 {
10168 PRINT(NVIDIA UvmInitialize ioctl);
10169 }

The right place to add it is PRE(sys_ioctl) and POST(sys_ioctl).

A more fundamental question is, are you running a kernel with NVidia-
specific hacks?  What is this ioctl 0x3001 ?  What does it do?  Is
it in the mainline linux kernel sources?

J


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Problem with helgrind?

[Julian Seward]

On 11/25/2014 10:22 AM, Pohl, Hartmut wrote:

 What confuses me is that the stack trace incorrectly reports a data race
 between the first and the second test thread. Which is impossible and makes me
 think that maybe the pthread_join() is incorrectly handled by helgrind?

There are a bunch of stack traces in this message.  Exactly which one is
the one you think is wrong?

I don't exactly understand the test program, but this ..

   bool wait = true;
   do
   {
 wait = atomicWait.syncLoad();
 ANNOTATE_HAPPENS_AFTER(atomicWait.getAddress());
   }
   while (wait) ;

.. doesn't feel right to me.  You need to put the ANNOTATE_HAPPENS_AFTER
after the end of the while loop, not inside it, because merely reading
the value

 wait = atomicWait.syncLoad();

doesn't mean the thread can go forwards.  It has to spin until that
value becomes |true|.  So the h-b edge from the main thread arrives
here after the loop, not inside it.

J


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Problem with helgrind?

[Julian Seward]

On 11/25/2014 02:04 PM, Pohl, Hartmut wrote:
 As far as I understand, Thread #5 belongs to the second test case and
 thus cannot have a data race with thread #3 due to the pthread_join()s.

I agree.

 I put the annotation at the end of the while (that's what I started with).

I looked at this in some detail, but I don't understand what is happening.

I did notice that if you comment out the line causing the real race

  i = 40;

then no races are reported.  So at least you have a situation where, if
there is a race, then (multiple) races are reported, but if you have no
race, then no races are reported.

To investigate further I'd need to look at Helgrind's memory state machine
transitions for |i|.

J


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.10.1 is available

[Julian Seward]

We are pleased to announce a new release of Valgrind, version 3.10.1,
available from http://www.valgrind.org.  See the attached release
notes for details.

Happy (and productive) debugging and profiling,

-- The Valgrind Developers


Release 3.10.1 (25 November 2014)
~
3.10.1 is a bug fix release.  It fixes various bugs reported in 3.10.0
and backports fixes for all reported missing AArch64 ARMv8 instructions
and syscalls from the trunk.  If you package or deliver 3.10.0 for others
to use, you might want to consider upgrading to 3.10.1 instead.

Note that this release does not contain backports of recent improvements
to support for MacOS 10.9 (Mavericks) or 10.10 (Yosemite).  If you are
looking for improved support on those targets, please try the trunk
instead, as described at http://valgrind.org/downloads/repository.html.

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=XX
where XX is the bug number as listed below.

335440  arm64: ld1 (single structure) is not implemented
335713  arm64: unhanded instruction: prfm (immediate)
339020  ppc64: memcheck/tests/ppc64/power_ISA2_05 failing in nightly build
339182  ppc64: AvSplat ought to load destination vector register with [..]
339336  PPC64 store quad instruction (stq) is not supposed to change [..]
339433  ppc64 lxvw4x instruction uses four 32-byte loads
339645  Use correct tag names in sys_getdents/64 wrappers
339706  Fix false positive for ioctl(TIOCSIG) on linux
339721  assertion 'check_sibling == sibling' failed in readdwarf3.c ...
339853  arm64 times syscall unknown
339855  arm64 unhandled getsid/setsid syscalls
339858  arm64 dmb sy not implemented
339926  Unhandled instruction 0x1E674001 (frintx) on aarm64
339927  Unhandled instruction 0x9E7100C6 (fcvtmu) on aarch64
339938  disInstr(arm64): unhandled instruction 0x4F8010A4 (fmla)
== 339950
339940  arm64: unhandled syscall: 83 (sys_fdatasync) + patch
340033  arm64: unhandled insn dmb ishld and some other isb-dmb-dsb variants
340028  unhandled syscalls for arm64 (msync, pread64, setreuid and setregid)
340036  arm64: Unhandled instruction ld4 (multiple structures, no offset)
340236  arm64: unhandled syscalls: mknodat, fchdir, chroot, fchownat
340509  arm64: unhandled instruction fcvtas
340630  arm64: fchmod (52) and fchown (55) syscalls not recognized
340632  arm64: unhandled instruction fcvtas
340725  AVX2: Incorrect decoding of vpbroadcast{b,w} reg,reg forms
340788  warning: unhandled syscall: 318 (getrandom)
340807  disInstr(arm): unhandled instruction: 0xEE989B20
340856  disInstr(arm64): unhandled instruction 0x1E634C45 (fcsel)
340922  arm64: unhandled getgroups/setgroups syscalls
n-i-bz  DRD and Helgrind: Handle Imbe_CancelReservation (clrex on ARM)
n-i-bz  Add missing ]] to terminate CDATA.
n-i-bz  Glibc versions prior to 2.5 do not define PTRACE_GETSIGINFO
n-i-bz  Enable sys_fadvise64_64 on arm32.
n-i-bz  Add test cases for all remaining AArch64 SIMD, FP and memory insns.
n-i-bz  Add test cases for all known arm64 load/store instructions.
n-i-bz  PRE(sys_openat): when checking whether ARG1 == VKI_AT_FDCWD [..]
n-i-bz  Add detection of old ppc32 magic instructions from bug 278808.
n-i-bz  exp-dhat: Implement missing function dh_malloc_usable_size.
n-i-bz  arm64: Implement fcvtpu w, s.
n-i-bz  arm64: implement ADDP and various others
n-i-bz  arm64: Implement {S,U}CVTF (scalar, fixedpt).
n-i-bz  arm64: enable FCVT{A,N}S X,S.

(3.10.1: 25 November 2014, vex r3026, valgrind r14785)

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] massif instrumentation in C/C++ code

[Julian Seward]

On 11/20/2014 09:04 AM, Peter Toft wrote:
 One thing that I often is missing with valgrind/massif is a way to know 
 know where I roughly am in my code when I see a given memory peak.
 
 I could envision to add a valgrind-macro or alike in my C-code to 
 indicate where I am in my code add (tentative syntax)

 Does something remotely similar to this already exist?

Not as far as I can see.  I had a look through ms_main.c but it doesn't
seem to support any client requests.

One thing you might consider is to use the stack recording facilities,
VG_(get_ExeContext), to get a stack trace for each for each snapshot
that Massif makes.  Not sure how you'd combine the output with the
existing output, though.

J


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Mac OS X 10.10 (Yosemite) support

[Julian Seward]

There has been some effort recently to improve Valgrind's support for
Yosemite.  If you develop on Mac OS, you might like to try out the
trunk (svn co svn://svn.valgrind.org/valgrind/trunk) and report any
breakage you get.  Support for Yosemite is good enough that at least
one large graphical application (Firefox) runs OK.  Support for the
previous release, 10.9 (Mavericks), is also substantially improved.

Note that the work has targetted 64 bit processes only.  32 bit might
work, and probably better on Mavericks, but I suspect it will be
increasingly problematic on Yosemite due to Valgrind's 32 bit x86
instruction set support not having progressed passed SSSE3.

J

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Call for Proposals: Valgrind developer room, FOSDEM 2015, Brussels, 31 Jan 2015

[Julian Seward]

Valgrind developer room at FOSDEM 2015 (Brussels, Belgium, 31 January).

FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate.  It is renown for being
highly developer-oriented and brings together 5000+ hackers from all
over the world.  It is held in the city of Brussels (Belgium).
http://fosdem.org/

FOSDEM 2015 will take place during the weekend of Saturday, 31 January
and Sunday 1 February 2015.  On Saturday we will have a devroom for
Valgrind.  Devrooms are a place for development teams to meet,
discuss, hack and publicly present the project's latest improvements
and future directions.

We will have a whole day to hang out together as Valgrind community.
Please join us, regardless of whether you are a Valgrind core hacker,
Valgrind tool hacker, Valgrind user, Valgrind packager or hacker on a
project that integrates, extends or complements Valgrind.

Call For Participation

We would like to organize a series of talks/discussions on various
topics relevant to both core hackers, new developers, users, packagers
and cross project functionality.  Please do submit a talk proposal by
Monday 1 December 2014, so we can make a list of activities during the
day.

Some possible topics for talks/discussions are:

- Recently added functional changes (for valgrind users).

- State of the valgrind code base (core hackers).

- Speeding up Memcheck by inlining of the fast cases of its helper
  function calls (core hackers).

- Supporting Valgrind on MacOS X 10.9 (Mavericks) and 10.10 (Yosemite)
  (valgrind developers and users).

- The AArch64 ARMv8 port (valgrind developers and users).

- Valgrind and Wine (valgrind developers and users).

- Helgrind - basic design, problems and opportunities (core and tools).

- Get feedback on what what kinds of new functionality would
  be useful. Which tools users would like to see and/or which new
  features for the existing tools. (valgrind developers and users).

  - Modify memcheck to report the last leaked pointer to a block
integrate omega as a memcheck option or omega as a separate tool.

  - Better support compiled and JITted code.
allowing the JIT compiler to indicate the link between
the JITted code and the source code.

  - Valgrind and transactional memory.

- How to add simple features (adding syscalls for a platform or VEX
  instructions for a architecture port). (new core developers).

- Making Valgrind really multi-threaded, parallelising Memcheck
  parallelising the rest of the framework, and tools (for core hackers).

- Should we continue to support MacOS? What about Valgrind on
  MS-Windows? Solaris? (attracting new hackers).

- Redo the JIT framework to reduce baseline overheads? (core hackers).

- Make Callgrind work sanely on ARM (core hackers).

- Discuss release/bugfixing strategy/policy (core hackers, packagers).

- Packaging valgrind for distros, handling patches, suppressions, etc.
  (packagers).

- Valgrind/GDB integration (cross project).

- Valgrind vs the compiler. Compilers like GCC and clang now have
  valgrind like features, eg -fsanitize=address|thread|undefined.
  How does valgrind complement or improve on these features?

- Eclipse and other visualisation tools for valgrind (cross project).

- Practical examples of using Valgrind in (big) system automatic
  regression testing (users).

Use the FOSDEM 'pentabarf' tool to submit your proposal.
https://penta.fosdem.org/submission/FOSDEM15/

- If necessary, create a Pentabarf account and activate it.

- In the Person section, provide First name, Last name
  (in the General tab), Email (in the Contact tab)
  and Bio (Abstract field in the Description tab).

- Submit a proposal by clicking on Create event.

- Important! Select the Valgrind devroom track
  (on the General tab).

- Provide the title of your talk (Event title in the General tab).

- Provide a description of the subject of the talk and the
  intended audience (in the Abstract field of the Description tab)

- Provide a rough outline of the talk or goals of the session (a short
  list of bullet points covering topics that will be discussed) in the
  Full description field in the Description tab

Julian, Philippe and Mark will review the proposals and organize the
schedule for the day.  Please feel free to suggest or discuss any ideas
for the devroom on the Valgrind developer mailinglist before creating a
proposal: valgrind-develop...@lists.sourceforge.net

Recording of talks

This year the FOSDEM organisers plan to have live streaming and
recording fully working, both for remote/later viewing of talks, and
so that people can watch streams in the hallways when rooms are full.
This obviously requires speakers to consent to being recorded and
streamed.  If you plan to be a speaker, please understand that by
doing so you implicitly give consent for your talk to be recorded and
streamed.  The recordings will be published under the same licence as
all FOSDEM content 

Re: [Valgrind-users] Spam (7.009):Re: valgrind-3.10 does not link on

[Julian Seward]

On 10/29/2014 09:24 AM, Florian Krohm wrote:
 I've fixed this in revision 14673.
 Curious, what GCC version have you been using?

I think the deciding factor might be, not the gcc version, but the CPU
variant being compiled for.  In particular that some AMDs do or don't have
special variants of these in hardware, or some such.

J


--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Did valgrind ever work in arm64-android?

[Julian Seward]

 I wonder if anyone ever tried valgrind in arm64-android.

So far, development has been on standard arm64-linux.  It should be
pretty simple to get it working on arm64-android, mostly a question
of fixing the missing instructions that are required.

I don't have a 64-bit Android device to test on, which doesn't help.
Is it possible to have remote access to one?

J


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Wrapping function for strcpy

[Julian Seward]

On 09/23/2014 03:31 AM, Myoungkyu Song wrote:
 I have a question, which maybe was discussed.  I would like to implement a
 wrapper function for standard API such as strcpy.  However, I failed to
 do.  When I tested a user-defined function like hello(char *, char *)
 below, I successfully wrapped it, accessing to arguments and a return
 value.

The problem is here

 char* I_WRAP_SONAME_FNNAME_ZU(NONE,strcpy) ( char *dest, const char *src )

By using (NONE,strcpy) you are requesting to wrap the function strcpy in
the main executable (that's what NONE) means.  But strcpy lives in
libc.so.  Really you need to use VG_Z_LIBC_SONAME (with a suitable
definition for VG_Z_LIBC_SONAME) to make it work.  Unfortunately the
definition of VG_Z_LIBC_SONAME is system-dependent.

You should be able to find all the examples you need in
shared/vg_replace_strmem.c

Note also, using -v is very helpful for debugging wrapping/intercept
problems.  If you need complete details, also try --trace-redir=yes.

J




--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind-3.10 does not link on

[Julian Seward]

Er, this isn't good.  Can you file a bug report
as described at http://www.valgrind.org/support/bug_reports.html
so that this gets tracked properly?  If it just remains on the mailing
list it is likely to get forgotten.

Thanks.

J


On 09/18/2014 10:09 AM, Matthias Apitz wrote:
 
 Hello,
 
 This is on a Linux host running:
 
 valgrind-3.10.0 uname -a
 Linux SRAP03DXOH 2.6.5-7.191-bigsmp #1 SMP Tue Jun 28 14:58:56 UTC 2005 i686 
 athlon i386 GNU/Linux
 
 valgrind-3.10.0 CFLAGS=-DPTRACE_GETSIGINFO=0x4202 export CFLAGS
 valgrind-3.10.0 ./configure
 valgrind-3.10.0 gmake
 ...
 
 mv -f .deps/memcheck_x86_linux-mc_errors.Tpo 
 .deps/memcheck_x86_linux-mc_errors.Po
 ../coregrind/link_tool_exe_linux 0x3800 gcc  -Wno-long-long 
 -DPTRACE_GETSIGINFO=0x4202   -o memcheck-x86-linux -m32 
 -mpreferred-stack-boundary=2 -O2 -g -Wall -Wmissing-prototypes -Wshadow 
 -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations 
 -Wno-format-zero-length -fno-strict-aliasing -fno-builtin 
 -fomit-frame-pointer -O2 -static -nodefaultlibs -nostartfiles -u _start  -m32 
 memcheck_x86_linux-mc_leakcheck.o memcheck_x86_linux-mc_malloc_wrappers.o 
 memcheck_x86_linux-mc_main.o memcheck_x86_linux-mc_translate.o 
 memcheck_x86_linux-mc_machine.o memcheck_x86_linux-mc_errors.o 
 ../coregrind/libcoregrind-x86-linux.a ../VEX/libvex-x86-linux.a -lgcc 
 ../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-syswrap-linux.o)(.text+0x14bba):
  In function `vgSysWrap_linux_sys_ioctl_after':
 m_syswrap/syswrap-linux.c:8476: undefined reference to `__builtin_popcountll'
 ../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-syswrap-linux.o)(.text+0x1ddcb):
  In function `vgSysWrap_linux_sys_ioctl_before':
 m_syswrap/syswrap-linux.c:5748: undefined reference to `__builtin_popcountll'
 collect2: ld returned 1 exit status
 gmake[3]: *** [memcheck-x86-linux] Error 1
 gmake[3]: Leaving directory 
 `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0/memcheck'
 gmake[2]: *** [all-recursive] Error 1
 gmake[2]: Leaving directory 
 `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0/memcheck'
 gmake[1]: *** [all-recursive] Error 1
 gmake[1]: Leaving directory 
 `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0'
 gmake: *** [all] Error 2
 
 Vy 73
 
  matthias
 


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind and glibc's CPU detection

[Julian Seward]

You need to say what CPU this is on.  For x86_64 I think this is
impossible, because all x86_64 processors support at least SSE2.

For x86 (32 bit) this might just be possible.  In VEX/priv/guest_x86_toIR.c,
find the code that handles CPUID

  case 0xA2: { /* CPUID */

and change it so that it uses this case

 if (archinfo-hwcaps == 0/*no SSE*/) {
fName = x86g_dirtyhelper_CPUID_sse0;
fAddr = x86g_dirtyhelper_CPUID_sse0;
 } else

J


On 09/23/2014 11:44 AM, Konstantin Tokarev wrote:
 Hi all,
 
 I'd like to prevent glibc from using any SIMD-optimized functions when 
 running 
 application under Valgrind on Linux. Is it possible to do now?
 AFAIU, glibc uses runtime CPU detection, and Valgrind runs code on emulated 
 CPU.
 


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind run error , help me, thx

[Julian Seward]

That's a bit strange.  Can you please try with the recently released
3.10.0 version, and see if you still have the problem?

Thanks.

J


On 09/25/2014 01:41 PM, lchquan wrote:
 # /opt/vg/bin/valgrind ls
 ==5290== Memcheck, a memory error detector
 ==5290== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
 ==5290== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
 ==5290== Command: ls
 ==5290== 
 ==5290== 
 ==5290== Process terminating with default action of signal 4 (SIGILL)
 ==5290==  Illegal opcode at address 0x3808AE70
 ==5290==at 0x4000E50: _start (in /lib/ld-uClibc-0.9.32.1.so)
  valgrind: m_scheduler/scheduler.c:957 (run_thread_for_a_while): Assertion 
 'done_this_time = 0' failed.
 ==5290==at 0x38039528: report_and_quit (m_libcassert.c:260)
 ==5290==by 0xE08F4003: ???
  sched status:
   running_tid=1
  Thread 1: status = VgTs_Runnable
 ==5290==at 0x4000E50: _start (in /lib/ld-uClibc-0.9.32.1.so)
  
 Note: see also the FAQ in the source distribution.
 It contains workarounds to several common problems.
 In particular, if Valgrind aborted or crashed after
 identifying problems in your program, there's a good chance
 that fixing those problems will prevent Valgrind aborting or
 crashing, especially if it happened in m_mallocfree.c.
  If that doesn't help, please report this bug to: www.valgrind.org
  In the bug report, send all the above text, the valgrind
 version, and what OS and version you are using.  Thanks.
  # cat /proc/cpu
 /proc/cpu/ /proc/cpuinfo
 # cat /proc/cpuinfo 
 Processor   : ARMv7 Processor rev 1 (v7l)
 processor   : 0
 BogoMIPS: 1987.37
  processor   : 1
 BogoMIPS: 1993.93
  Features: swp half thumb fastmult edsp tls 
 CPU implementer : 0x41
 CPU architecture: 7
 CPU variant : 0x4
 CPU part: 0xc09
 CPU revision: 1
  Hardware: hi3535
 Revision: 
 Serial  : 
  # uname -a  
 Linux (none) 3.4.35_hi3535 #4 SMP Tue Jul 22 11:14:11 CST 2014 armv7l 
 GNU/Linux
  # /opt/vg/bin/valgrind --version
 valgrind-3.9.0
 
  what's wrong with me?
 
 
 
 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 
 
 
 ___
 Valgrind-users mailing list
 Valgrind-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/valgrind-users
 


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Problems with valgrind after a fork() and starting a container

[Julian Seward]

Yes, if you get some details on how/why it fails, that would
be good.  Also, filing a bug in bugzilla
(see http://www.valgrind.org/support/bug_reports.html)
will ensure your bug report doesn't get lost later on.

J



On 09/25/2014 02:58 PM, Vallevand, Mark K wrote:
 I tried that option.  Doesn’t help.
 I was afraid that it would be what Tom said.  [Theatrical sigh]
 I have a couple of choices, I guess.  Find out why valgrind and lxc aren’t 
 working together and fix that.  Or, do some kind of exec() outside of lxc.
 The lxc_start() that is being called is a kind of exec(), I guess.  It 
 creates a new set of namespaces and does a clone() and exec() in them.  That 
 is where is it failing.  I’m trying to get a log file with more details.  
 There might be a chance to figure this out.
 
 Regards.
 Mark K Vallevand
 If there are no dogs in Heaven, then when I die I want to go where they 
 went.
 -Will Rogers
 
 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
 MATERIAL and is thus for use only by the intended recipient. If you received 
 this in error, please contact the sender and delete the e-mail and its 
 attachments from all computers.
 From: Alan Copy [mailto:alan.c...@gmail.com]
 Sent: Thursday, September 25, 2014 06:51 AM
 To: Tom Hughes
 Cc: Vallevand, Mark K; valgrind-users@lists.sourceforge.net
 Subject: Re: [Valgrind-users] Problems with valgrind after a fork() and 
 starting a container
 
 hi,
 
 Tom is right you can detach if you don't use exec but i think you can silent 
 child output using --child-silent-after-fork=no
 Alan
 
 2014-09-24 23:45 GMT+02:00 Tom Hughes 
 t...@compton.numailto:t...@compton.nu:
 On 24/09/14 22:04, Vallevand, Mark K wrote:
 
 We don’t care about valgrind in the child process.  We need to get the
 child to detach from valgrind before it calls the lxc library.

 So, how can this be done?
 
 It can't - valgrind is a fundamental part of the process and the only
 way to get rid of it is to exec into a different binary.
 
 Tom
 
 --
 Tom Hughes (t...@compton.numailto:t...@compton.nu)
 http://compton.nu/
 
 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Valgrind-users mailing list
 Valgrind-users@lists.sourceforge.netmailto:Valgrind-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/valgrind-users
 
 
 
 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 
 
 
 ___
 Valgrind-users mailing list
 Valgrind-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/valgrind-users
 


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Unique log filename

[Julian Seward]

On 09/25/2014 12:52 PM, Eliot Moss wrote:
 I started updating the valgrind documentation to add description
 of this new feature, and expect to submit a patch soon for
 developer approval.

https://bugs.kde.org/show_bug.cgi?id=339405
is the bug, yes?

J


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Possible bug in valgrind?

[Julian Seward]

This is HTM lock elision stuff; 3.9.0 doesn't support it but 3.10.0.BETA2
might well do.

 I have tried googling on this error but I am not finding much related to
 it. Any ideas on how to fix it?

Try with
http://www.valgrind.org/downloads/valgrind-3.10.0.BETA2.tar.bz2
instead.

J


--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.10.0 BETA 2 is available for testing

[Julian Seward]

A second beta tarball for 3.10.0 is available now at
http://www.valgrind.org/downloads/valgrind-3.10.0.BETA2.tar.bz2
(md5sum = 785115cf1a3f25afa8d0a97df6a1a879)

Please give it a try in configurations that are important for you, and
report any problems you have, either on this mailing list, or
(preferably) via our bug tracker at
https://bugs.kde.org/enter_bug.cgi?product=valgrind

If nothing critical emerges, a final release is likely to happen
on Thursday 11 Sept.

Compared to the first beta, there have been a number of fixes for
debuginfo reading, and for running on MacOSX.  Inlining-aware
stack unwinding has been enabled by default for Memcheck/Helgrind/DRD
on Linux targets.  Various other bugs have also been fixed.

J

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.10.0 BETA is available for testing

[Julian Seward]

A beta tarball for 3.10.0 is available now at
http://www.valgrind.org/downloads/valgrind-3.10.0.BETA1.tar.bz2
(md5sum = dee188c79a9795fee178ba17f42c40b3)

Please give it a try in configurations that are important for you, and
report any problems you have, either on this mailing list, or
(preferably) via our bug tracker at
https://bugs.kde.org/enter_bug.cgi?product=valgrind

If nothing critical emerges, a final release is likely to happen late
next week.

For details about what's new in 3.10, see the NEWS file in the
tarball.  Some of the highlights are:

- Initial support for AArch64 ARMv8 (64-bit ARM)
- 64-bit LE POWER Architecture support
- much improved MacOSX 10.9 support
- MIPS32 support for Android
- stack traces through inlined function calls
- EXIDX unwinding on ARM
- Improved error messages for Memcheck and Helgrind
- Reduced memory use for storing debug info
- A huge number of bug fixes

J


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind-3.10.0 BETA is available for testing

[Julian Seward]

On 09/03/2014 02:47 PM, Phil Longstaff wrote:
 Is more information available about these changes?
 I'd like to see more detail on improved error messages
 and stack traces through inlined function calls.

Sure.  Here is the entire NEWS entry for the release so far.

J


Release 3.10.0 (mid September 2014)
~~~

3.10.0 is not yet released.  This is a beta of 3.10.0.

3.10.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, X86/Android, X86/MacOSX 10.9
and AMD64/MacOSX 10.9.  Support for MacOSX 10.8 and 10.9 is
significantly improved relative to the 3.9.0 release.

* == PLATFORM CHANGES =

* Support for the 64-bit ARM Architecture (AArch64 ARMv8).  This port
  is mostly complete, and is usable, but some SIMD instructions are as
  yet unsupported.

* Support for little-endian variant of the 64-bit POWER architecture.

* Support for Android on MIPS32.

* Support for 64bit FPU on MIPS32 platforms.

* Both 32- and 64-bit executables are supported on MacOSX 10.8 and 10.9.

* == DEPRECATED FEATURES =

* --db-attach is now deprecated and will be removed in the next
  valgrind feature release.  The built-in GDB server capabilities are
  superior and should be used instead. Learn more here:
  http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver

*  TOOL CHANGES 

* Memcheck:

  - Client code can now selectively disable and re-enable reporting of
invalid address errors in specific ranges using the new client
requests VALGRIND_DISABLE_ADDR_ERROR_REPORTING_IN_RANGE and
VALGRIND_ENABLE_ADDR_ERROR_REPORTING_IN_RANGE.

  - Leak checker: there is a new leak check heuristic called
length64.  This is used to detect interior pointers pointing 8
bytes inside a block, on the assumption that the first 8 bytes
holds the value block size - 8.  This is used by
sqlite3MemMalloc, for example.

  - Checking of system call parameters: if a syscall parameter
(e.g. bind struct sockaddr, sendmsg struct msghdr, ...) has
several fields not initialised, an error is now reported for each
field. Previously, an error was reported only for the first
uninitialised field.

  - Mismatched alloc/free checking: a new flag
--show-mismatched-frees=no|yes [yes] makes it possible to turn off
such checks if necessary.

* Helgrind:

  - Improvements to error messages:

o Race condition error message involving heap allocated blocks also
  show the thread number that allocated the raced-on block.

o All locks referenced by an error message are now announced.
  Previously, some error messages only showed the lock addresses.

o The message indicating where a lock was first observed now also
  describes the address/location of the lock.

  - Helgrind now understands the Ada task termination rules and
creates a happens-before relationship between a terminated task
and its master.  This avoids some false positives and avoids a big
memory leak when a lot of Ada tasks are created and terminated.
The interceptions are only activated with forthcoming releases of
gnatpro = 7.3.0w-20140611 and gcc = 5.0.

  - A new GDB server monitor command info locks giving the list of
locks, their location, and their status.

* Callgrind:

  - callgrind_control now supports the --vgdb-prefix argument,
which is needed if valgrind was started with this same argument.

*  OTHER CHANGES 

* Unwinding through inlined function calls.  By default, stack
  unwinding now makes use of Dwarf3 inlined-unwind information if it
  is available.  The practical effect is that inlined calls become
  visible in stack traces.  The suppression matching machinery has
  been adjusted accordingly.  This is controlled by the new option
  --read-inline-info=yes|no [yes].

  In the 3.10.0 beta release(s), inlined unwinding is only enabled for
  Memcheck and Helgrind.  It is hoped to enable it for all tools in
  the 3.10.0 final release.

* Valgrind can now read EXIDX unwind information on 32-bit ARM
  targets.  If an object contains both CFI and EXIDX unwind
  information, Valgrind will prefer the CFI over the EXIDX.  This
  facilitates unwinding through system libraries on arm-android
  targets.

* Address description logic has been improved and is now common
  between Memcheck and Helgrind, resulting in better address
  descriptions for some kinds of error messages.

* Error messages about dubious arguments (eg, to malloc or calloc) are
  output like other errors.  This means that they can be suppressed
  and they have a stack trace.

* The C++ demangler has been updated for better C++11 support.

* New and 

Re: [Valgrind-users] memory barriers support

[Julian Seward]

On 08/19/2014 02:31 PM, Jan Včelák wrote:
 I believe the problem originates in some kind of race.

Try --fair-sched=yes to see if you can reproduce the problem more
often and/or more reliably.

J



--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Complete precise profiling

[Julian Seward]

On 08/16/2014 03:19 AM, Van Snyder wrote:
 It seems that cachegrind could be extended to do complete precise
 profiling.

What do you mean by complete precise profiling?  Can you clarify?

J



--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind doesnot show any memory Leaks

[Julian Seward]

I think we saw recently (last couple of months?) a case where Memcheck
didn't do any intercepts with uClibC, and it turned out that the problem
was that uClibc had not been built with LD_PRELOAD support.  So the
intercept .so never got loaded into the process.  I wonder if that is
the case here?

J

On 07/09/2014 12:43 PM, Philippe Waroquiers wrote:
 On Wed, 2014-07-09 at 15:58 +0530, Jonnavithula Sharma wrote:
 Hi ,

 ...
 But somehow there were no leaks detected and the output is as
 below(attached is the complete valgrind output)
 
 ...
 Any suggestions or help is highly appreciated.


 I am compiling my application with all debug options as well. I was
 struck and not able to proceed ahead.
 
 The most frequent source of this kind of problems is the fact
 that the malloc library is statically linked with your app.
 
 You must then indicate that to valgrind, using the option
--soname-synonyms=...
 (see user manual for details).
 
 If that is not the case, then the 2nd most frequent source of problem
 is that the redirection of the malloc etc symbols are not done
 due to the name of the library not being what is expected by valgrind.
 Use the options -v -v -v -d -d -d --trace-redir=yes
 and try to understand what is going wrong.
 
 
 Philippe
 
 
 
 
 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 Valgrind-users mailing list
 Valgrind-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/valgrind-users
 


--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind doesn't detect leaks on Linux/ARM with uClibc

[Julian Seward]

On 05/21/2014 05:24 PM, Andrejs Bogdanovs wrote:
 Hi Julian!
 
 Soname for malloc intercepts should be one defined in VG_Z_LIBC_SONAME?
 include/pub_tool_redir.h:244:#  define  VG_Z_LIBC_SONAME  libcZdsoZa
// libc.so*
 And soname for libuClibc-0.9.33.2.so is libc.so.0:
 [andrejs@arch ~]$ readelf -a ./dev_libs/lib/libuClibc-0.9.33.2.so | grep 
 soname
  0x000e (SONAME) Library soname: [libc.so.0]

That soname looks ok, then.  But from the log you posted
later, it is clear that there is no malloc intercepting happening.

For malloc intercepting to work, the files vgpreload_core-arm-linux.so
and vgpreload_memcheck-amd64-linux.so need to be loaded into the process.

Comparing your log with a run with a glibc based system, I see this

  Reading syms from [..]/vgpreload_core-amd64-linux.so
  Reading syms from [..]/vgpreload_memcheck-amd64-linux.so

which is missing in your log.

Does uCLibc implement LD_PRELOAD?  I think that is how Valgrind causes
those two objects to be loaded into the process.

J



--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Need assistance with diagnosing failure cause

[Julian Seward]

On 04/14/2014 12:05 PM, Lior Tal wrote:
 I am getting an error when executing valgrind with the following options:
 
 valgrind --tool=memcheck --leak-check=full --dsymutil=yes
 --read-var-info=yes --log-file=$VALGRIND_LOG ./$MACHO_NAME

Try removing --read-var-info=yes.

J


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] ARMv8 port available for testing

[Julian Seward]

The trunk now contains a port to AArch64 ARMv8 -- loosely, the
64-bit ARM architecture.  It has now reached a stage of being
useful for real debugging, and, in turn, could do with wider
testing.

Memcheck works and has a noise (false-error) level that is
comparable with other targets.  All the basic functionality --
detection of uninitialised value uses, invalid memory accesses,
detection of leaks, and origin tracking -- is available.  Other
tools -- Lackey, Cachegrind, Callgrind, Massif, DRD and Helgrind
-- work to some extent, but have not been extensively tested.

Current limitations are:

* Incomplete support of vector (SIMD) instructions.  Anything
  created by gcc-4.8.2 -O3, including SIMD code via
  autovectorization, works.  Completion of the SIMD support is
  ongoing.

* Incomplete syscall support.  Enough system calls are supported
  for large programs to work, but some are still unsupported.

* Integration with the built in GDB server is incomplete.

There has been extensive testing of the supported of integer, FP
and SIMD instructions.  At least one large application -- Firefox
26 -- is able to start up and quit.  The port is under active
development and will ship as part of the next release, Valgrind 3.10.

See README.aarch64 for instructions on how to build and run the port.

J

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] possible to add debug symbol information after a valgrind run?

[Julian Seward]

On 04/07/2014 10:26 PM, Bob Kuo wrote:
 Is it possible to run valgrind *without* the debug symbols available
 and then take the valgrind log output, the .map, and the debug symbols
 to get a full stack trace?  That would simplify our testing greatly.

In theory you might be able to use addr2line, but you'd need to do some
arithmetic -- basically, subtract the library actual load address --
before you can give those addresses to addr2line.

The usual problem with running V on embedded targets is (1) that it
takes forever to move the debuginfo objects onto the target, and (2)
doing so uses up all the flash storage on the target.  If your target
can communicate with the build host using TCP/IP, you might like to try
running V's debuginfo server on the host (auxprogs/valgrind-di-server.c)
and asking V on the target to use that, using --debuginfo-server=.

It's pretty crude (needs work) but it does just about work.

J


--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Callgrind: where do I find the list of event names?

[Julian Seward]

(guessing at both questions; JosefW would know for definite)

 The default callgrind run and callgrind_annonate display shows Ir events, but
 I only need to count function entries. Is there a way to only collect those
 and have callgrind run faster??

I suspect not.  In any case counting insns is not terribly expensive, so the
gain you'd get would be modest.

 callgrind_annotate has the --show option to only show specific events, but I
 can't find a list of event names to feed it. Where should I be looking?

I suspect the names are present in the callgrind.out file, and so
callgrind_annotate just slices out those that you list.  It doesn't
itself know the names.  But what part of the .c files of callgrind
generates the names, I have no idea.

J


--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.9.0 is available

[Julian Seward]

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

3.9.0 is a feature release with many improvements and the usual
collection of bug fixes.  This release adds support for MIPS64/Linux,
Intel AVX2 instructions and POWER8 instructions.  DFP support has been
added for S390.  Initial support for hardware transactional memory has
been added for Intel and POWER platforms.  Support for Mac OS X 10.8
(Mountain Lion) has been improved.  Accuracy of Memcheck on vectorized
code has been improved.

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.

Happy and productive debugging and profiling,

-- The Valgrind Developers


Release 3.9.0 (31 October 2013)
~~~
3.9.0 is a feature release with many improvements and the usual
collection of bug fixes.

This release supports X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux,
PPC64/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android,
X86/Android, X86/MacOSX 10.7 and AMD64/MacOSX 10.7.  Support for
MacOSX 10.8 is significantly improved relative to the 3.8.0 release.

* == PLATFORM CHANGES =

* Support for MIPS64 LE and BE running Linux.  Valgrind has been
  tested on MIPS64 Debian Squeeze and Debian Wheezy distributions.

* Support for MIPS DSP ASE on MIPS32 platforms.

* Support for s390x Decimal Floating Point instructions on hosts that
  have the DFP facility installed.

* Support for POWER8 (Power ISA 2.07) instructions

* Support for Intel AVX2 instructions.  This is available only on 64
  bit code.

* Initial support for Intel Transactional Synchronization Extensions,
  both RTM and HLE.

* Initial support for Hardware Transactional Memory on POWER.

* Improved support for MacOSX 10.8 (64-bit only).  Memcheck can now
  run large GUI apps tolerably well.

*  TOOL CHANGES 

* Memcheck:

  - Improvements in handling of vectorised code, leading to
significantly fewer false error reports.  You need to use the flag
--partial-loads-ok=yes to get the benefits of these changes.

  - Better control over the leak checker.  It is now possible to
specify which leak kinds (definite/indirect/possible/reachable)
should be displayed, which should be regarded as errors, and which
should be suppressed by a given leak suppression.  This is done
using the options --show-leak-kinds=kind1,kind2,..,
--errors-for-leak-kinds=kind1,kind2,.. and an optional
match-leak-kinds: line in suppression entries, respectively.

Note that generated leak suppressions contain this new line and
are therefore more specific than in previous releases.  To get the
same behaviour as previous releases, remove the match-leak-kinds:
line from generated suppressions before using them.

  - Reduced possible leak reports from the leak checker by the use
of better heuristics.  The available heuristics provide detection
of valid interior pointers to std::stdstring, to new[] allocated
arrays with elements having destructors and to interior pointers
pointing to an inner part of a C++ object using multiple
inheritance.  They can be selected individually using the
option --leak-check-heuristics=heur1,heur2,...

  - Better control of stacktrace acquisition for heap-allocated
blocks.  Using the --keep-stacktraces option, it is possible to
control independently whether a stack trace is acquired for each
allocation and deallocation.  This can be used to create better
use after free errors or to decrease Valgrind's resource
consumption by recording less information.

  - Better reporting of leak suppression usage.  The list of used
suppressions (shown when the -v option is given) now shows, for
each leak suppressions, how many blocks and bytes it suppressed
during the last leak search.

* Helgrind:

  - False errors resulting from the use of statically initialised
mutexes and condition variables (PTHREAD_MUTEX_INITIALISER, etc)
have been removed.

  - False errors resulting from the use of pthread_cond_waits that
timeout, have been removed.

*  OTHER CHANGES 

* Some attempt to tune Valgrind's space requirements to the expected
  capabilities of the target:

  - The default size of the translation cache has been reduced from 8
sectors to 6 on Android platforms, since each sector occupies
about 40MB when using Memcheck.

  - The default size of the translation cache has been increased to 16
sectors on all other platforms, reflecting the fact that large
applications require instrumentation and storage of huge amounts
of code.  For similar reasons, the number of memory mapped
segments that can be tracked has been increased by a factor of 6.

  - In 

Re: [Valgrind-users] mysterious failures when using valgrind

[Julian Seward]

On 09/26/2013 04:47 PM, John Reiser wrote:
 The likely cause is __float128 operations being performed as double 
 precision
 of two __float80 by the Intel math library for x86_64.  Memcheck-3.8.1 
 implements
 __float80 operations as __float64 (ordinary IEEE-754 'double'.)
 
 Thanks for analyzing this! I assume this means that a fix will be rather 
 complex?
 
 Nearly every user whose programs utilize 80-bit x86 floating point
 is disappointed by memcheck's 64-bit implementation of 80-bit operations.
 This situation is many years old.  The fix requires a major effort
 of design and implementation.

I'd say it would take about 2-3 weeks for a developer that is familiar
with the VEX IR and the x86_64 front and back ends, to do this.  It
is complex in that it requires changes to the front end, back end, and
to register allocation.  It would also be necessary to check that the
changes don't cause performance regressions for (real) 64-bit FP insns
on x86_64.

So it's not impossible, but given the number and urgency of some of the
other bugs we're faced with, it has so far been difficult to make a case
for allocating developer resources to this.

J


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Running Java 5 under Valgrind results in Valgrind silently dying

[Julian Seward]

On 08/13/2013 10:27 PM, Maynard Johnson wrote:

 When I try running Java 5 under current Valgrind (checkout from SVN today),
 it results in Valgrind silently dying.  The JVM continues to run, but only
 the java process shows up in 'top' output.  If I run Java 6 under
 Valgrind
 (i.e., 'valgrind --tool=memcheck /opt/ibm/java-ppc64-60/jre/bin/java test'),
 I see all of the typical kind of memcheck output, as well as the 
 'memcheck-ppc64-'
 command listed in top output.  I'm seeing this problem on IBM POWER7/RHEL 6.4,
 but I don't have a Java 5 available for my laptop to test it on Intel.
 Is this a ppc64-specific problem? Or an IBM Java-specific problem?
 Can anyone reproduce with Java 5 on an Intel system? Thanks.

I can't guess .. can you get more info about the failure?  Also, as per
other postings, you need --smc-check=all-non-file for Java anything on
x86.

J


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users