valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Unable to setup valgrind on Android

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

It is a very long time I did not compile valgrind for android
(and when I did it years ago, I used an android emulator), so likely
I will not be able to help much.

Did you read and follow the README.android instructions ?
(sounds a little bit unexpected that the below error message seems
to indicate you have a rooted x86-linux smartphone).

So, in particular, check the output of the configure step,
as mentioned in README.android.

Philippe


On Thu, 2021-04-08 at 05:07 +0530, Nikhil Agrawal wrote:
> Hi everyone,
> I am new to the usage of Valgrind. I am getting this error when I executed ./valgrind on my adb shell on rooted smartphone.
> > valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory
> 
> May I know how to resolve it. It will be a big help for my research work.
> -- 
> Nikhil Agrawal,
> MTech(Research) Student,
> Computer Science and Automation Department
> IISc Bangalore-560012
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Unable to setup valgrind on Android

[Nikhil A. <nik...@gm...>]

Hi everyone,
I am new to the usage of Valgrind. I am getting this error when I executed
./valgrind on my adb shell on rooted smartphone.

> valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No
> such file or directory

May I know how to resolve it. It will be a big help for my research work.
-- 
Nikhil Agrawal,
MTech(Research) Student,
Computer Science and Automation Department
IISc Bangalore-560012

Re: [Valgrind-users] Segfault / wxWidgets & Boost

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

Looks a little bit difficult to tell anything precise based on the info you provide.

As general guidelines:
  * If the server segfaults, you should have a core dump to debug and see what went wrong.
    If core dump is disabled (e.g. check ulimit -a), you might also just
    attach with gdb and have gdb stop when the segfault is encountered.
  * And of course, you can try to run your program under valgrind.
Philippe

On Fri, 2021-03-26 at 13:22 -0400, John A wrote:
> Hey y'all,
> 
> I am attempting to solve a unique problem with our inhouse software. The
> main client and server are C/C++. There is also a GUI server using wxWidgets
> 3.1.
> 
> Any guidance to this would be helpful: many or 1 client(s) are begun and
> connect locally or via TCP to the server GUI instance. When a client
> disconnects, the server GUI segfaults.
> 
> We're using Boost 1.74/1.76 (rc2)
> 
> Best regards,
> John
> 
> aronetics.com
> We Speak ITR
> +1-216/307-5760
> 
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Segfault / wxWidgets & Boost

[John A <jo...@ar...>]

Hey y'all,

I am attempting to solve a unique problem with our inhouse software. The
main client and server are C/C++. There is also a GUI server using wxWidgets
3.1.

Any guidance to this would be helpful: many or 1 client(s) are begun and
connect locally or via TCP to the server GUI instance. When a client
disconnects, the server GUI segfaults.

We're using Boost 1.74/1.76 (rc2)

Best regards,
John

aronetics.com
We Speak ITR
+1-216/307-5760

[Valgrind-users] Valgrind-3.17.0 is available

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

We are pleased to announce a new release of Valgrind, version 3.17.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.17.0 fixes a number of bugs and adds some functional changes: support for
GCC 11, Clang 11, DWARF5 debuginfo, the 'debuginfod' debuginfo server, and
some new instructions for Arm64, S390 and POWER.  There are also some tool
updates.

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.17.0 (19 Mar 2021)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3.17.0 fixes a number of bugs and adds some functional changes: support for
GCC 11, Clang 11, DWARF5 debuginfo, the 'debuginfod' debuginfo server, and
some new instructions for Arm64, S390 and POWER.  There are also some tool
updates.

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

* DWARF version 5 support.  Valgrind can now read DWARF version 5 debuginfo as
  produced by GCC 11.

* Valgrind now supports debuginfod, an HTTP server for distributing ELF/DWARF
  debugging information. When a debuginfo file cannot be found locally,
  Valgrind is able to query debuginfod servers for the file using its
  build-id. See the user manual for more information about debuginfod support.

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

* arm64:

  - Inaccuracies resulting from double-rounding in the simulation of
    floating-point multiply-add/subtract instructions have been fixed.  These
    should now behave exactly as the hardware does.

  - Partial support for the ARM v8.2 instruction set.  v8.2 support work is
    ongoing.  Support for the half-word variants of at least the following
    instructions has been added:
       FABS <Hd>, <Hn>
       FABS <Vd>.<T>, <Vn>.<T>
       FNEG <Hd>, <Hn>
       FNEG <Vd>.<T>, <Vn>.<T>
       FSQRT <Hd>, <Hn>
       FSQRT <Vd>.<T>, <Vn>.<T>
       FADDP

* s390:

  - Implement the new instructions/features that were added to z/Architecture
    with the vector-enhancements facility 1.  Also cover the instructions from
    the vector-packed-decimal facility that are defined outside the chapter
    "Vector Decimal Instructions", but not the ones from that chapter itself.

    For a detailed list of newly supported instructions see the updates to
    `docs/internals/s390-opcodes.csv'.

    Since the miscellaneous instruction extensions facility 2 was already
    added in Valgrind 3.16.0, this completes the support necessary to run
    general programs built with `--march=z14' under Valgrind.  The
    vector-packed-decimal facility is currently not exploited by the standard
    toolchain and libraries.

* ppc64:

  - Various bug fixes.  Fix for the sync field to limit setting just two of
    the two bits in the L-field. Fix the write size for the stxsibx and
    stxsihx instructions.  Fix the modsw and modsd instructions.

  - Partial support for ISA 3.1 has been added.  Support for the VSX PCV mask
    instructions, bfloat16 GER instructions, and bfloat16 to/from float 32-bit
    conversion instructions are still missing.

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

* General tool changes

  - All the tools and their vgpreload libraries are now installed under
    libexec because they cannot be executed directly and should be run through
    the valgrind executable. This should be an internal, not user visible,
    change, but might impact valgrind packagers.

  - The --track-fds option now respects -q, --quiet and won't output anything
    if no file descriptors are leaked. It also won't report the standard stdin
    (0), stdout (1) or stderr (2) descriptors as being leaked with
    --trace-fds=yes anymore. To track whether the standard file descriptors
    are still open at the end of the program run use --trace-fds=all.

* DHAT:

  - DHAT has been extended, with two new modes of operation. The new
    --mode=copy flag triggers copy profiling, which records calls to memcpy,
    strcpy, and similar functions. The new --mode=ad-hoc flag triggers ad hoc
    profiling, which records calls to the DHAT_AD_HOC_EVENT client request in
    the new dhat/dhat.h file. This is useful for learning more about hot code
    paths. See the user manual for more information about the new modes.

  - Because of these changes, DHAT's file format has changed. DHAT output
    files produced with earlier versions of DHAT will not work with this
    version of DHAT's viewer, and DHAT output files produced with this version
    of DHAT will not work with earlier versions of DHAT's viewer.

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

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

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

140178  open("/proc/self/exe", ...); doesn't quite work
140939 --track-fds reports leakage of stdout/in/err and doesn't respect -q
217695  malloc/calloc/realloc/memalign failure doesn't set errno to ENOMEM
338633  gdbserver_tests/nlcontrolc.vgtest hangs on arm64
345077  linux syscall execveat support (linux 3.19)
361770  Missing F_ADD_SEALS
369029  handle linux syscalls sched_getattr and sched_setattr
384729  __libc_freeres inhibits cross-platform valgrind
388787  Support for C++17 new/delete
391853  Makefile.all.am:L247 and @SOLARIS_UNDEF_LARGESOURCE@ being empty
396656  Warnings while reading debug info
397605  ioctl FICLONE mishandled
401416  Compile failure with openmpi 4.0
408663  Suppression file for musl libc
404076  s390x: z14 vector instructions not implemented
410743  shmat() calls for 32-bit programs fail when running in 64-bit valgrind
        (actually affected all x86 and nanomips regardless of host bitness)
413547  regression test does not check for Arm 64 features.
414268  Enable AArch64 feature detection and decoding for v8.x instructions
415293  Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave*
422174  unhandled instruction bytes: 0x48 0xE9 (REX prefixed JMP instruction)
422261  platform selection fails for unqualified client name
422623  epoll_ctl warns for uninitialized padding on non-amd64 64bit arches
423021  PPC:  Add missing ISA 3.0 documentation link and HWCAPS test.
423195  PPC ISA 3.1 support is missing, part 1
423361  Adds io_uring support on arm64/aarch64 (and all other arches)
424012  crash with readv/writev having invalid but not NULL arg2 iovec
424298  amd64: Implement RDSEED
425232  PPC ISA 3.1 support is missing, part 2
425820  Failure to recognize vpcmpeqq as a dependency breaking idiom.
426014  arm64: implement fmadd and fmsub as Iop_MAdd/Sub
426123  PPC ISA 3.1 support is missing, part 3
426144  Fix "condition variable has not been initialized" on Fedora 33.
427400  PPC ISA 3.1 support is missing, part 4
427401  PPC ISA 3.1 support is missing, part 5
427404  PPC ISA 3.1 support is missing, part 6
427870  lmw, lswi and related PowerPC insns aren't allowed on ppc64le
427787  Support new faccessat2 linux syscall (439)
427969  debuginfo section duplicates a section in the main ELF file
428035  drd: Unbreak the musl build
428648  s390_emit_load_mem panics due to 20-bit offset for vector load
428716  cppcheck detects potential leak in VEX/useful/smchash.c
428909  helgrind: need to intercept duplicate libc definitions for Fedora 33
429352  PPC ISA 3.1 support is missing, part 7
429354  PPC ISA 3.1 support is missing, part 8
429692  unhandled ppc64le-linux syscall: 147 (getsid)
429864  s390x: C++ atomic test_and_set yields false-positive memcheck
        diagnostics
429952  Errors when building regtest with clang
430354  ppc stxsibx and stxsihx instructions write too much data
430429  valgrind.h doesn't compile on s390x with clang
430485  expr_is_guardable doesn't handle Iex_Qop
431556  Complete arm64 FADDP v8.2 instruction support
432102  Add support for DWARF5 as produced by GCC11
432161  Addition of arm64 v8.2 FADDP, FNEG and FSQRT
432381  drd: Process STACK_REGISTER client requests
432552  [AArch64] invalid error emitted for pre-decremented byte/hword addresses
432672  vg_regtest: test-specific environment variables not reset between tests
432809  VEX should support REX.W + POPF
432861  PPC modsw and modsd give incorrect results for 1 mod 12
432870  gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64
432215  Add debuginfod functionality
433323  Use pkglibexecdir as vglibdir
433500  DRD regtest faulures when libstdc++ and libgcc debuginfo are installed
433629  valgrind/README has type "abd" instead of "and"
433641  Rust std::sys::unix::fs::try_statx Syscall param fstatat(file_name)
433898  arm64: Handle sp, lr, fp as DwReg in CfiExpr
434193  GCC 9+ inlined strcmp causes "Conditional jump or move [..]
value" report
n-i-bz  helgrind: If hg_cli__realloc fails, return NULL.
n-i-bz  arm64 front end: avoid Memcheck false positives relating to CPUID

(3.17.0.RC1: 13 Mar 2021)
(3.17.0.RC2: 17 Mar 2021)
(3.17.0:     19 Mar 2021)

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBFy189QBCACxFf0SSSycE42ulnIYk7GNR9FnKlDN4rNZ9TExYWMh6cJIELgq
W5eI9xoHJarfLc7uSKPagcGPIntThCMBw8dLnL8mFzsCOIrjQl/C9FZua53RwmzE
t6+yvMJMcYz8Vqfh7J8w5+zlAMFSqbE5jAcWEzlaz8YMt8GTgixhFSC6eyy0j+4L
k35+lKOvX1htUIjVYz9nfVgGmz6Vg+2dyjxoB6GHXtrAExRuoo0jqctLc8dZOp0U
MMzVEQzJItcYj6/L1FEOYcrnhVri92sgB+AReMWy1ailt+OmNXmEkpV5L4vCJn2Y
sThu7OnecBUoMMP13y2UB23h3vlxe0RyxuZNABEBAAG0H0p1bGlhbiBTZXdhcmQg
PGpzZXdhcmRAYWNtLm9yZz6JATgEEwECACIFAly189QCGwMGCwkIBwMCBhUIAgkK
CwQWAgMBAh4BAheAAAoJELoBZuaY+mA1ttoH/0MkIQcB4QohV2Z9Fkf95jm6uz/P
rFewPS7iyRMLL9sPktjqXg0X1yxX5ShpEbtL18X+qbAVDIe98uTdyFb21b8DjP6n
v2KnIZFDD+iZEceWJD6MAXcicvr4sv4LESzreNEIF6wHdWkWC4v57hQl+uywWXiI
T4gnHUEJIu0cNP3vMcSjrgrzeaPW3z56B+BLBM1XncrZ0mbz77/FK9lQM1arLpcU
dPNJlVMqNdbLLlIsmkZ8jfE7TCOCNuIrCHeNTRGY5NuY829pheGwutIlp4t+Pchz
/cib3hZeilJrFuuqBOk4ipZ/s1PwS9DigGOk1I0egqIBhPdAsEY3gBXdOXyJAjME
EAEKAB0WIQTsPP6I9soHiHdPXB0apEvmSd52CgUCXLYy8gAKCRAapEvmSd52CnJb
D/45yMDDnSelx6MfBwQcowqkkK/BzZs+akR5hX76g5alMSA2MRBkudGO8R/G2fva
sa9e2Js+3crmoyOxfL3PCun/N7/J2rX8PPT6d4hk1N3fluUWghUhCDMHmfPy1N5d
WMTTW/EvZrYdh1dauGw/k+DP/M784FN8UU15hggMCcqM5LGNKuMOhFadntecj/Wr
aAtroLD3Geq7eUAO18oYgJFRktdXtDkWGTG6+KhoLTIaW8xRAR1OiO6Oxua+3htU
Zrk9AIDAJQymeA9budWyVAMPZSgnkSdMQBe8UnwsCx1X6xZP+wHihZ86oClydieh
3AtsLzjzZGNytAO7+BP7cNxvrWXBNUMTEQwAcMp8PbjV3NAK/96sfdQ++3wttvMw
4M4AI0hFxE67EkpTjk0rDhDINjOowyn/MBpNuuC2BuDlzrR7AV8jKq957OMko6uk
S/NlJo9LUYeyLSU1lF5B6fh6tu3Tyv4yASTp6fyihh+G24azAbYi4WQu79ltuDQb
Zg4fGVB/vcydsf1NxiEQMMSOyrcws+WNYjqGymZ70YZW+PDEBZcW4WE515RR0N3N
3YmLbvIywYQe2zKFOoLu2CDx/q/gqMX0W9I4h3sSKOoFIFkeY7Cr/6OdV6S1Re9d
o/dGoKDzfjaXpTZf4Kv19wEizElnoi7S7tFrbLLMV1vQHrkBDQRctfPUAQgAtKTF
G5HFIUs8kO3Cs3EysJhOe/pEIYhkdRwKn46ostfk7Ghd4YdwRYDscZaqrwCaY1lV
VLKd33IPdFHpGwRQrM0RyLA+A6xfdoCoKO0vOLTEiEDI+C3FDSZ/vCeq13gMfYHN
tuhmEjvA9MMwKx0/kfKc28fQWPDDDgnAQ6cyS+9t4s4j6JuRm/rq4blKWGK8f8Ob
KrEFHt/J1uhLykGbgYFu0MSaldevjHJzqzkscHcifAA5SMWZuYn5dMCNJT+8Iadr
u0TSCvZQeN3HceNCN2Liodpv/JqUn8qF5wGaUxZFcGdy5V+nR1PsQnguEd35Z1ai
rfqdE27KZYRC3xzO8wARAQABiQEfBBgBAgAJBQJctfPUAhsMAAoJELoBZuaY+mA1
NSUH/jUd12imDneXAMKt3ThlqXh1v0tPnawugaNHD3vibvgFYcyqQ+YbPMhRgUoc
hdTLbkqxkjEzfLhpzAA164AcP3/pDq+OCyyONNnt06LXxgGU2lJoTeRdSEsOFYxE
RnOUoW8qQoPWWk8ZmnMh/2VEuXeIjXMHNvdAWMn0gUfKDEeeCILpqkn4f4Sx4H5P
1Yf4JzgwYTfFocXDsQSsFrboAPOJVEm4E7zJfp62Uzs72+9NueHnZEnr4pVzCUIm
CxJrvQzGcJxc1eqbuCmI0zuFLRcgZUpO4a0IaDUsjhbG2PUTADgSAfgLihrvaiA+
xn/APcV8iSUjgKGcnQfuhhayxQk=
=C8ND
-----END PGP PUBLIC KEY BLOCK-----

[Valgrind-users] Access to internal cycle/instruction counters from the guest

[Arseny K. <ars...@gm...>]

I'm investigating ways to integrate instrumentation-based profiling with
cachegrind.

When running a native program, cachegrind can measure estimated instruction
counts and other metrics like cache misses etc., and attribute them to
specific functions based on the debug information.

However, sometimes this doesn't produce very useful results - for example,
when the profiled program is an interpreter, this produces profiling data
for the interpreter itself but not the interpreted program.

What I'd like to do is to be able to query some data - instruction
counters, cache misses, anything else of that sort that might be available
- from the guest, assuming it knows it's running under cachegrind.

I was initially hoping to be able to query instruction counters using
rdtsc, but rdtsc is implemented using the host rdtsc instruction, so it
generates very noisy data - I was hoping to be able to use internal
simulated counters to produce stable results.

Is there a way to do something like this without modifying cachegrind? (of
course I could hack rdtsc to do what I want in theory but that'd require
using custom binaries)

Arseny

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

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

Hi Carl,

On Wed, 2021-03-17 at 09:36 -0700, Carl Love wrote:
> On Wed, 2021-03-17 at 13:08 +0100, Mark Wielaard wrote:
> The testing on the ISA 3.1 because the file
> none/tests/ppc64/isa_3_1_register_defines.h is missing from RC2.  I
> checked and it is also missing from RC1.  The file does exist in the
> Vaglrind git tree.  Not sure why it is missing in the RCs.  Not sure
> why I didn't pick that up with the previous RC1 testing.  Sorry about
> that.

Oops. It looks like that was missed because it isn't used unless
building for ISA3.1. I committed the following to make sure it will be
in the final release tarball:

commit 8616808ab3cc691699bd1f733eb9b3106a1a6256
Author: Mark Wielaard <ma...@kl...>
Date:   Wed Mar 17 17:56:07 2021 +0100

    Add isa_3_1_register_defines.h to Makefile.am noinst_HEADERS
    
    Make sure isa_3_1_register_defines.h ends up in the dist tarball.

diff --git a/none/tests/ppc64/Makefile.am b/none/tests/ppc64/Makefile.am
index 23a22d922..38a3dc483 100644
--- a/none/tests/ppc64/Makefile.am
+++ b/none/tests/ppc64/Makefile.am
@@ -3,7 +3,7 @@ include $(top_srcdir)/Makefile.tool-tests.am
 
 dist_noinst_SCRIPTS = filter_stderr
 
-noinst_HEADERS = ppc64_helpers.h isa_3_1_helpers.h
+noinst_HEADERS = ppc64_helpers.h isa_3_1_helpers.h isa_3_1_register_defines.h
 
 EXTRA_DIST = \
        jm-int.stderr.exp jm-int.stdout.exp jm-int.vgtest jm-int.stdout.exp-LE \

Thanks,

Mark

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

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

Greetings.

A second release candidate for 3.17.0 is available at
https://sourceware.org/pub/valgrind/valgrind-3.17.0.RC2.tar.bz2
(md5 = 5dcf7c42635e19b074714c53f3a57580)

Thanks for the testing of RC1.
The changes between RC1 and RC2 are minimal:

- debuginfod-check.pl is now included to fix make regtest.
- libmpiwrap.c now compiles whether or not openmpi has MPI1 support.
- Two fixes for make check on Darwin/MacOS X are included.

Please give it a try on platforms that are important for you.  If no
serious issues are reported, the 3.17.0 final release will happen on 19
March, that is, on Friday of this week.

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

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

Hi Paul,

On Tue, Mar 16, 2021 at 09:07:56PM +0100, Paul Floyd wrote:
> 
> On 3/15/21 1:33 PM, Mark Wielaard wrote:
> > Greetings.
> > 
> > A first release candidate for 3.17.0 is available at
> > https://sourceware.org/pub/valgrind/valgrind-3.17.0.RC1.tar.bz2
> > (md5 = 9df201b3461a1709993ffc50d0920bd7)
> > 
> > Please give it a try on platforms that are important for you.  If no
> > serious issues are reported, the 3.17.0 final release will happen on 19
> > March, that is, on Friday of this week.
>
> Please let me know if you'd prefer me to push the two small changes in the
> tests described below now, or to wait after 3.17 ships.

I think it would be good to get these small fixes in and do an RC2
(including the mpi build fix) to make sure things build out of the box
on more setups.

> On OS X 10.7.5 (Darwin 11.4.2), I've tried a bit harder than usual to get
> everything to build at least. I still have a lot of compiler problems. The
> last available XCode for this platform is too old for the current Valgrind
> source (it doen't support some of the asm opcodes). So I've been using
> macports clang  (version 9 for the C code and 11 for the C++).
> 
> There's a small issue building dhat/tests/copy.c, it just needs a '||
> defined(VGO_darwin).

I assume because darwin, like solaris, doesn't have mempcpy.  That
should be fine.


> none/tests/tls isn't building - a link error with the TLS variable "__thread
> int global;". Needs more investigation.

That doesn't ring a bell.

> ./tests/arm64_features.c doesn't compile:
> 
> arm64_features.c:4:10: fatal error: 'sys/auxv.h' file not found
> #include <sys/auxv.h>
>          ^~~~~~~~~~~~
> 

Hmmm, that is for getauxval. That probably isn't available on
Darwin. I don't immediately know how to replace that.

Cheers,

Mark

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

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

On 3/15/21 1:33 PM, Mark Wielaard wrote:
> Greetings.
>
> A first release candidate for 3.17.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.17.0.RC1.tar.bz2
> (md5 = 9df201b3461a1709993ffc50d0920bd7)
>
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.17.0 final release will happen on 19
> March, that is, on Friday of this week.


Hi

Please let me know if you'd prefer me to push the two small changes in 
the tests described below now, or to wait after 3.17 ships.

On OS X 10.7.5 (Darwin 11.4.2), I've tried a bit harder than usual to 
get everything to build at least. I still have a lot of compiler 
problems. The last available XCode for this platform is too old for the 
current Valgrind source (it doen't support some of the asm opcodes). So 
I've been using macports clang  (version 9 for the C code and 11 for the 
C++).

There's a small issue building dhat/tests/copy.c, it just needs a '|| 
defined(VGO_darwin).

none/tests/tls isn't building - a link error with the TLS variable 
"__thread int global;". Needs more investigation.

./tests/arm64_features.c doesn't compile:

arm64_features.c:4:10: fatal error: 'sys/auxv.h' file not found
#include <sys/auxv.h>
          ^~~~~~~~~~~~

I'm running the regression tests. They are very slow so I might net get 
them tonight.

A+

Paul

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

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

Hi Carl,

On Mon, 2021-03-15 at 11:33 -0700, Carl Love wrote:
> Will Schmidt posted an email with regards to the build issue:
>   
>    I think so..  we ran into a similar issue late last year, which I
>    think
>    we had determined was due to the MPI packages in the
> environment.   
>    The patch in comment #3 of this bugzilla helped us at that time.  
>    https://bugs.kde.org/show_bug.cgi?id=401416

Thanks. That explains why I am not seeing it on Fedora, but you are
seeing it on Ubuntu. OpenMPI4 disables MPI1 support by default, but
fedora still enables it (for now).

> I applied the MPI patch to the mainline git tree on the system where
> I had the compile error.  It fixed the compile issue.  I applied the
> patch to another system which didn't have the compile issue.  The patch
> did not break anything.  As far as I can tell, the MPI patch is fine.

It seems fine if MPI1 is removed. But I am not 100% sure if it is fine
when you still have MPI1 support. I'll try and test it a bit.

> I pulled the mainline git tree and retested on Power 8LE, Power 8BE,
> Power 9, and prototype hardware.  The regression tests all look fine
> with the above mentioned MPI fix where needed.

Nice.

Thanks,

Mark

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

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

Hi Carl,

On Mon, 2021-03-15 at 09:05 -0700, Carl Love wrote:
> I am seeing issues on various power platforms.  
> 
> Power 8 BE
> 
>    gcc --version
>    gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
> 
>    more /etc/os-release
>    NAME=Fedora
>    VERSION="27 (Server Edition)"
>    ID=fedora
>    VERSION_ID=27
>    PRETTY_NAME="Fedora 27 (Server Edition)"
>    ANSI_COLOR="0;34"
>    CPE_NAME="cpe:/o:fedoraproject:fedora:27"
>    HOME_URL="https://fedoraproject.org/"
>    SUPPORT_URL="
>    https://fedoraproject.org/wiki/Communicating_and_getting_help"
>    BUG_REPORT_URL="https://bugzilla.redhat.com/"
>    REDHAT_BUGZILLA_PRODUCT="Fedora"
>    REDHAT_BUGZILLA_PRODUCT_VERSION=27
>    REDHAT_SUPPORT_PRODUCT="Fedora"
>    REDHAT_SUPPORT_PRODUCT_VERSION=27
>    PRIVACY_POLICY_URL="
>    https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
>    VARIANT="Server Edition"
>    VARIANT_ID=server
> 
> I am getting the following error while running make regtest
> 
>    leak-pool-4:     valgrind   ./leak-pool 4
>    leak-pool-5:     valgrind   ./leak-pool 5
>    leak-segv-jmp:   (skipping, prereq failed: ! ../../tests/os_test
>    darwin && ! ../../tests/arch_test mips32 && !
> ../../tests/arch_test
>    ppc64)
>    leak-tree:       valgrind   -q --leak-check=full --leak-
>    resolution=high ./leak-tree 
>    leak_cpp_interior: valgrind   --leak-check=summary --leak-check-
>    heuristics=multipleinheritance,stdstring,newarray,length64 --
>    suppressions=libstdc++.supp ./leak_cpp_interior 
>    -- Running  tests in memcheck/tests/linux ------------------------
> --
>    ----
>    brk:             valgrind   ./brk 
>    capget:          valgrind   ./capget 
>    /bin/sh: ./debuginfod-check.pl: No such file or directory
>    prereq returned 127: ./debuginfod-check.pl
>    ...checking makefile consistency
>    ...checking header files and include directives
>    make: *** [Makefile:1367: regtest] Error 1


Unfortunately debuginfod-check.pl was missing. I just added it:
https://sourceware.org/git/?p=valgrind.git;a=commit;h=3751e963fab1d644508a9c25b0f147ad609d5dff

> I see the same error on a Power 9
> 
>    more /etc/os-release
>    NAME="Ubuntu"
>    VERSION="18.04.5 LTS (Bionic Beaver)"
>    ID=ubuntu
>    ID_LIKE=debian
>    PRETTY_NAME="Ubuntu 18.04.5 LTS"
>    VERSION_ID="18.04"
>    HOME_URL="https://www.ubuntu.com/"
>    SUPPORT_URL="https://help.ubuntu.com/"
>    BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
>    PRIVACY_POLICY_URL="
>    https://www.ubuntu.com/legal/terms-and-policies/privacy-poli
> cy"
> VERSION_CODENAME=bionic
> UBUNTU_CODENAME=bionic
> 
> 
> I am seeing compilation issues on Power 8LE
> 
>    gcc --version
>    gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> 
>    NAME="Ubuntu"
>    VERSION="20.04.1 LTS (Focal Fossa)"
>    ID=ubuntu
>    ID_LIKE=debian
>    PRETTY_NAME="Ubuntu 20.04.1 LTS"
>    VERSION_ID="20.04"
>    HOME_URL="https://www.ubuntu.com/"
>    SUPPORT_URL="https://help.ubuntu.com/"
>    BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
>    PRIVACY_POLICY_URL="
>    https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
>    VERSION_CODENAME=focal
>    UBUNTU_CODENAME=focal
> 
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57:
> error: expected expression before ‘_Static_assert’
>      322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc)
> _Static_assert(0, #func " was removed in MPI-3.0.  Use " #newfunc "
> instead.")
>          |                                                         ^~
> ~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:1112:24:
> note: in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’
>     1112 | #        define MPI_UB
> THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_UB, MPI_Type_create_resized);
>          |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:281:19: note: in expansion of macro ‘MPI_UB’
>      281 |    else if (ty == MPI_UB)             fprintf(f,"UB");
>          |                   ^~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57:
> error: expected expression before ‘_Static_assert’
>      322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc)
> _Static_assert(0, #func " was removed in MPI-3.0.  Use " #newfunc "
> instead.")
>          |                                                         ^~
> ~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:1113:24:
> note: in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’
>     1113 | #        define MPI_LB
> THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_LB, MPI_Type_create_resized);
>          |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:282:19: note: in expansion of macro ‘MPI_LB’
>      282 |    else if (ty == MPI_LB)             fprintf(f,"LB");
>          |                   ^~~~~~
>    libmpiwrap.c: In function ‘showCombiner’:
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57:
> error: expected expression before ‘_Static_assert’
>      322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc)
> _Static_assert(0, #func " was removed in MPI-3.0.  Use " #newfunc "
> instead.")
>          |                                                         ^~
> ~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:743:46: note:
> in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’
>      743 | #        define MPI_COMBINER_HVECTOR_INTEGER
> THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HVECTOR_INTEGER,
> MPI_COMBINER_HVECTOR);
>          |                                              ^~~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:354:12: note: in expansion of macro
> ‘MPI_COMBINER_HVECTOR_INTEGER’
>      354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>          |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57:
> error: expected expression before ‘_Static_assert’
>      322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc)
> _Static_assert(0, #func " was removed in MPI-3.0.  Use " #newfunc "
> instead.")
>          |                                                         ^~
> ~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:743:46: note:
> in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’
>      743 | #        define MPI_COMBINER_HVECTOR_INTEGER
> THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HVECTOR_INTEGER,
> MPI_COMBINER_HVECTOR);
>          |                                              ^~~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:354:12: note: in expansion of macro
> ‘MPI_COMBINER_HVECTOR_INTEGER’
>      354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>          |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:354:40: error: expected expression before ‘:’ token
>      354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>          |                                        ^
>    In file included from libmpiwrap.c:116:
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57:
> error: expected expression before ‘_Static_assert’
>      322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc)
> _Static_assert(0, #func " was removed in MPI-3.0.  Use " #newfunc "
> instead.")
>          |                                                         ^~
> ~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:744:47: note:
> in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’
>      744 | #        define MPI_COMBINER_HINDEXED_INTEGER
> THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HINDEXED_INTEGER,
> MPI_COMBINER_HINDEXED);
>          |                                               ^~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:359:12: note: in expansion of macro
> ‘MPI_COMBINER_HINDEXED_INTEGER’
>      359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>          |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57:
> error: expected expression before ‘_Static_assert’
>      322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc)
> _Static_assert(0, #func " was removed in MPI-3.0.  Use " #newfunc "
> instead.")
>          |                                                         ^~
> ~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:744:47: note:
> in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’
>      744 | #        define MPI_COMBINER_HINDEXED_INTEGER
> THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HINDEXED_INTEGER,
> MPI_COMBINER_HINDEXED);
>          |                                               ^~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:359:12: note: in expansion of macro
> ‘MPI_COMBINER_HINDEXED_INTEGER’
>      359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>          |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:359:41: error: expected expression before ‘:’ token
>      359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>          |                                         ^
>    In file included from libmpiwrap.c:116:
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57:
> error: expected expression before ‘_Static_assert’
>      322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc)
> _Static_assert(0, #func " was removed in MPI-3.0.  Use " #newfunc "
> instead.")
>          |                                                         ^~
> ~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:745:45: note:
> in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’
>      745 | #        define MPI_COMBINER_STRUCT_INTEGER
> THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_STRUCT_INTEGER,
> MPI_COMBINER_STRUCT);
>          |                                             ^~~~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:366:12: note: in expansion of macro
> ‘MPI_COMBINER_STRUCT_INTEGER’
>      366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>          |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57:
> error: expected expression before ‘_Static_assert’
>      322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc)
> _Static_assert(0, #func " was removed in MPI-3.0.  Use " #newfunc "
> instead.")
>          |                                                         ^~
> ~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:745:45: note:
> in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’
>      745 | #        define MPI_COMBINER_STRUCT_INTEGER
> THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_STRUCT_INTEGER,
> MPI_COMBINER_STRUCT);
>          |                                             ^~~~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:366:12: note: in expansion of macro
> ‘MPI_COMBINER_STRUCT_INTEGER’
>      366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>          |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:366:39: error: expected expression before ‘:’ token
>      366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>          |                                       ^
>    libmpiwrap.c: In function ‘extentOfTy’:
>    libmpiwrap.c:462:8: warning: implicit declaration of function
> ‘PMPI_Type_extent’; did you mean ‘MPI_Type_extent’? [-Wimplicit-
> function-declaration]
>      462 |    r = PMPI_Type_extent(ty, &n);
>          |        ^~~~~~~~~~~~~~~~
>          |        MPI_Type_extent
>    In file included from libmpiwrap.c:116:
>    libmpiwrap.c: In function ‘walk_type’:
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57:
> error: expected expression before ‘_Static_assert’
>      322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc)
> _Static_assert(0, #func " was removed in MPI-3.0.  Use " #newfunc "
> instead.")
>          |                                                         ^~
> ~~~~~~~~~~~~
>    /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:1113:24:
> note: in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’
>     1113 | #        define MPI_LB
> THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_LB, MPI_Type_create_resized);
>          |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    libmpiwrap.c:736:17: note: in expansion of macro ‘MPI_LB’
>      736 |       if (ty == MPI_LB || ty == MPI_UB)
>          |                 ^~~~~~
>    make[2]: *** [Makefile:716: libmpiwrap_ppc64le_linux_so-
> libmpiwrap.o] Error 1
>    make[2]: Leaving directory '/home/carll/Valgrind/valgrind-
> 3.17.0.RC1/mpi'
>    make[1]: *** [Makefile:855: check-recursive] Error 1
>    make[1]: Leaving directory '/home/carll/Valgrind/valgrind-
> 3.17.0.RC1'
>    make: *** [Makefile:1149: check] Error 2
> 
> I will dig into this a bit more and see if I can find a fix for the
> error.  I will let you know.

I just did a build on Fedora, and I am not seeing these issues. It
might depend on the version of openmpi installed I assume.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1723501

Cheers,

Mark

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

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

Greetings.

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

Please give it a try on platforms that are important for you.  If no
serious issues are reported, the 3.17.0 final release will happen on 19
March, that is, on Friday of this week.

Re: [Valgrind-users] CPU simulation and instruction simulation

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

On 06/02/2021 07:59, Muhui Jiang wrote:

> I am new to Valgrind and have some questions about the principles of 
> Valgrind.
> 
> According to the manual, 
> https://valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes 
> <https://valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes>
> "Your program is then run on a synthetic CPU provided by the Valgrind core."
> "Valgrind simulates every single instruction your program executes"
> 
> I am curious that as a binary instrumentation framework, why Valgrind 
> needs to simulate the CPU and instruction execution. It seems that the 
> host and guest architecture must be the same due to the multiple 
> syscalls.  If so, why not use the host CPU to run the translated binary 
> directly instead of simulation? Simulated instruction execution might be 
> different from the execution on physical devices.

It does run on the native CPU because valfrind is a JIT that converts
the original instructions to an internal form which it analyses and
instruments and then converts the instrumented code back into native
code which is then run on the real processor.

But from the point of view of the program it is running on valgrind's
emulated CPU and can only use those instructions and features which
valgrind knows how to emulate.

> The other question is that what part is simulated for a CPU except for 
> the instruction execution. Are the memory model, cache, and registers 
> all simulated/emulated. Any suggestions and comments are welcome. Many 
> Thanks

The cache is simulated in parallel for cachegrind/callgrind in order
to generate estimated statistics for cache hit/misses.

Tom

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

[Valgrind-users] CPU simulation and instruction simulation

[Muhui J. <jia...@gm...>]

Hi all

I am new to Valgrind and have some questions about the principles of
Valgrind.

According to the manual,
https://valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes
"Your program is then run on a synthetic CPU provided by the Valgrind core."
"Valgrind simulates every single instruction your program executes"

I am curious that as a binary instrumentation framework, why Valgrind needs
to simulate the CPU and instruction execution. It seems that the host and
guest architecture must be the same due to the multiple syscalls.  If so,
why not use the host CPU to run the translated binary directly instead of
simulation? Simulated instruction execution might be different from the
execution on physical devices.

The other question is that what part is simulated for a CPU except for the
instruction execution. Are the memory model, cache, and registers all
simulated/emulated. Any suggestions and comments are welcome. Many Thanks

Regards
Muhui

Re: [Valgrind-users] using valgrind to debug uninitialized mem in servern

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

On 04/02/2021 10:57, Matthias Apitz wrote:
> El día jueves, febrero 04, 2021 a las 09:48:23a. m. +0000, Tom Hughes escribió:
> 
>> On 04/02/2021 09:26, Matthias Apitz wrote:
>>
>>> At the moment we use the following "trick": the librarian runs in
>>> parallel to the client on the desktop a second window with a "tail -f ..."
>>> on valgrinds log file (STDOUT) and the full screen is recorded with
>>> Microsoft teams functionality. So we can use the timestamps in the log
>>> to go to the replay of the recording and can see what the user did
>>> exactly, which data was entered and which button pressed etc.
>>>
>>> Are there other ideas to bring together the valgrind log and the usage
>>> of the application?
>>
>> You could instrument the request processing logic to log details
>> of the request if any errors are detected while processing it, so
>> something like:
>>
>>    #include "valgrind/valgrind.h"
>>
>>    return_type process_request(...)
>>    {
>>      int errors = VALGRIND_COUNT_ERRORS;
>>
>>      // process request as normal
>>
>>      if (VALGRIND_COUNT_ERRORS > errors)
>>      {
>>        VALGRIND_PRINTF("Saw errors processing request %s", request_name);
>>      }
>>    }
>>
>> Obviously you can change it to log whatever details you want.
> 
> Thanks, this looks like a good plan!
> 
> The above are macros, are there additional shared libs to link with our
> process?

No - the valgrind client directives work by generating a special
sequence of assembly language instructions that is spotted by the
valgrind virtual machine and causes valgrind to generate a call to
an internal routine.

Tom

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

Re: [Valgrind-users] using valgrind to debug uninitialized mem in servern

[Matthias A. <gu...@un...>]

El día jueves, febrero 04, 2021 a las 09:48:23a. m. +0000, Tom Hughes escribió:

> On 04/02/2021 09:26, Matthias Apitz wrote:
> 
> > At the moment we use the following "trick": the librarian runs in
> > parallel to the client on the desktop a second window with a "tail -f ..."
> > on valgrinds log file (STDOUT) and the full screen is recorded with
> > Microsoft teams functionality. So we can use the timestamps in the log
> > to go to the replay of the recording and can see what the user did
> > exactly, which data was entered and which button pressed etc.
> > 
> > Are there other ideas to bring together the valgrind log and the usage
> > of the application?
> 
> You could instrument the request processing logic to log details
> of the request if any errors are detected while processing it, so
> something like:
> 
>   #include "valgrind/valgrind.h"
> 
>   return_type process_request(...)
>   {
>     int errors = VALGRIND_COUNT_ERRORS;
> 
>     // process request as normal
> 
>     if (VALGRIND_COUNT_ERRORS > errors)
>     {
>       VALGRIND_PRINTF("Saw errors processing request %s", request_name);
>     }
>   }
> 
> Obviously you can change it to log whatever details you want.

Thanks, this looks like a good plan!

The above are macros, are there additional shared libs to link with our
process?

> 
> The only issue might be that if the code is multithreaded and can
> process multiple requests in parallel then you won't know which
> thread the errors came from.

No, they're singlethreaded. A master daemon forks for any connecting
client a new server proc.

	matthias

-- 
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: [Valgrind-users] using valgrind to debug uninitialized mem in servern

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

On 04/02/2021 09:26, Matthias Apitz wrote:

> At the moment we use the following "trick": the librarian runs in
> parallel to the client on the desktop a second window with a "tail -f ..."
> on valgrinds log file (STDOUT) and the full screen is recorded with
> Microsoft teams functionality. So we can use the timestamps in the log
> to go to the replay of the recording and can see what the user did
> exactly, which data was entered and which button pressed etc.
> 
> Are there other ideas to bring together the valgrind log and the usage
> of the application?

You could instrument the request processing logic to log details
of the request if any errors are detected while processing it, so
something like:

   #include "valgrind/valgrind.h"

   return_type process_request(...)
   {
     int errors = VALGRIND_COUNT_ERRORS;

     // process request as normal

     if (VALGRIND_COUNT_ERRORS > errors)
     {
       VALGRIND_PRINTF("Saw errors processing request %s", request_name);
     }
   }

Obviously you can change it to log whatever details you want.

The only issue might be that if the code is multithreaded and can
process multiple requests in parallel then you won't know which
thread the errors came from.

Tom

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

[Valgrind-users] using valgrind to debug uninitialized mem in servern

[Matthias A. <gu...@un...>]

Hello,

The following is not fully on-topic because it's more a question related
to how to use valgrind in our case. But maybe others have had similar
questions or a solution...

We have fat application servers, written in C/C++ on top of a DBS
(PostgreSQL). These application servers offer the business logic in a
Library Management System to application clients, written in Java, and
used by the librarian staff of the institutions. Both, server and
client, communicate over a TCP/IP protocol, developed for this purpose
by us: the librarian works with client, the client sends business
oriented commands to the app server, this does its work in the DBS and gives
responses to the client.

We do valgrinding the server and from time to time valgrind detects a
problem, for example usage of not initialized memory access, or jumps
based on this, etc.

Sometimes it is very difficult to find the exact reason for valgrind's
complaint and one has to use a gdb and for this to redo what the server
was executing, or better what the librarian did exactly with the client
that caused the server to execute this particular  piece of code and
with which data input.

At the moment we use the following "trick": the librarian runs in
parallel to the client on the desktop a second window with a "tail -f ..." 
on valgrinds log file (STDOUT) and the full screen is recorded with
Microsoft teams functionality. So we can use the timestamps in the log
to go to the replay of the recording and can see what the user did
exactly, which data was entered and which button pressed etc.

Are there other ideas to bring together the valgrind log and the usage
of the application?

Thanks for reading this.

	matthias
-- 
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: [Valgrind-users] printing the values of arguments for strcpy(3), memmove(3), ...

[Matthias A. <gu...@un...>]

El día martes, enero 26, 2021 a las 02:40:26p. m. -0800, John Reiser escribió:

> > The reason was at the end of debugging that we replaced in some central
> > place of the server a function call (due to vg messages about
> > overlapping args)
> > 
> > 	strncpy(dst, src, n);
> > 
> > by
> > 
> > 	memset(dst, 0, n);
> > 	memmove(dst, src, n);
> > 
> > which is not fully equivalent because strncpy(3) will stop at the first
> > \0 byte in src, while memmove(3) will copy n bytes, regardles if they
> > are valid bytes in src. As this was in some low level function, it
> > generated a mass of the above vg messages.
> [[snip]]
> > Any thoughts about this?
> 
> You may have a much bigger problem than you realize.  Take paper
> and pencil; write TEN TIMES (this is not a joke!):
> 
>      strncpy(dst, src, n) always over-writes exactly n bytes
>      (namely dst[0..(n-1)]), regardless of strlen(src).

I know this. strncpy(dst, src, n) writes strlen(src) bytes to dst and
fills the rest in dst until n with \0 bytes. This is clear but not the point of
the problem. The problem is (was) that strncpy(dst, src, n) only
reads(!) strlen(src) bytes from src, while memmove(dst, src, n) reads n
bytes from src and if n > strlen(src) it reads illegal bytes, raised as
an error by valgrind correctly.

	matthias


-- 
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
¡Con Cuba no te metas!  «»  Don't mess with Cuba!  «»  Leg Dich nicht mit Kuba an!
http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/

Re: [Valgrind-users] [valgrind]: mem leaks

[Kunal C. <atk...@gm...>]

++ by using that flag my process is affecting, or there is some thread
optimization flags in valgrind so fruit full logs can be generate

On Wed, Jan 27, 2021 at 11:00 PM Kunal Chauhan <atk...@gm...>
wrote:

> Thanks for hint or approach.
> but My concern was, my valgrind is displaying 1000 error but I want
> valgrind should not stop at error limit .
> as I used --error limit option in valgrind my process some threads does
> not work or process in not well executing.
>
> On Wed, Jan 27, 2021 at 9:42 PM Paul Floyd <pj...@wa...> wrote:
>
>>
>> On 1/27/21 4:31 PM, Kunal Chauhan wrote:
>> > As you said if valgrind is just a same as my process with some extra
>> > messages. But as I facing in valgrind when i used  valgrind option
>> > like --errorlimit=no then my process some threads are not working .
>> >
>> > And if my do not use error limit flag  valgrind saying 1000 error
>> > reached and it will not display more errors , how can i come out of
>> > this situation.
>> >
>>
>> I was only referring to segmentation faults.
>>
>>
>> If there are other errors you will have to fix them. Just start at with
>> the first one and continue.
>>
>>
>> Regards
>>
>> Paul
>>
>>
>>
>
> --
> *Thanks with Regards!*
>
> *Kunal Chauhan*
> *Mob:09813614826*
> *Mob:08860397903*
>
> *E-mail:atk...@gm... <E-mail%3Aa...@gm...>*
>
>

-- 
*Thanks with Regards!*

*Kunal Chauhan*
*Mob:09813614826*
*Mob:08860397903*

*E-mail:atk...@gm... <E-mail%3Aa...@gm...>*

Re: [Valgrind-users] [valgrind]: mem leaks

[Kunal C. <atk...@gm...>]

Thanks for hint or approach.
but My concern was, my valgrind is displaying 1000 error but I want
valgrind should not stop at error limit .
as I used --error limit option in valgrind my process some threads does not
work or process in not well executing.

On Wed, Jan 27, 2021 at 9:42 PM Paul Floyd <pj...@wa...> wrote:

>
> On 1/27/21 4:31 PM, Kunal Chauhan wrote:
> > As you said if valgrind is just a same as my process with some extra
> > messages. But as I facing in valgrind when i used  valgrind option
> > like --errorlimit=no then my process some threads are not working .
> >
> > And if my do not use error limit flag  valgrind saying 1000 error
> > reached and it will not display more errors , how can i come out of
> > this situation.
> >
>
> I was only referring to segmentation faults.
>
>
> If there are other errors you will have to fix them. Just start at with
> the first one and continue.
>
>
> Regards
>
> Paul
>
>
>

-- 
*Thanks with Regards!*

*Kunal Chauhan*
*Mob:09813614826*
*Mob:08860397903*

*E-mail:atk...@gm... <E-mail%3Aa...@gm...>*

Re: [Valgrind-users] [valgrind]: mem leaks

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

> On 25 Jan 2021, at 11:49, Kunal Chauhan <atk...@gm...> wrote:
> 
> Thanks for clarifications
> ++ if the binary is crashed or may be not crashed when it runs with valgrind, but in both case valgrind is able to give the report. ?


Hi

If your application causes a segmentation fault, the OS will send it a SIGSEGV signal. When it is running inside Valgrind, Valgrind will see whether or not your application has a signal handler. If not it will print a message describing the fault and also instructions as to what you should do in the unlikely event that the cause is a stack overflow in your program’s main thread.

In short, Valgrind will do the same as you application would do running outsizde of Valgrind, just with a lot more messages.

A+
Paul

Re: [Valgrind-users] printing the values of arguments for strcpy(3), memmove(3), ...

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

> The reason was at the end of debugging that we replaced in some central
> place of the server a function call (due to vg messages about
> overlapping args)
> 
> 	strncpy(dst, src, n);
> 
> by
> 
> 	memset(dst, 0, n);
> 	memmove(dst, src, n);
> 
> which is not fully equivalent because strncpy(3) will stop at the first
> \0 byte in src, while memmove(3) will copy n bytes, regardles if they
> are valid bytes in src. As this was in some low level function, it
> generated a mass of the above vg messages.
[[snip]]
> Any thoughts about this?

You may have a much bigger problem than you realize.  Take paper
and pencil; write TEN TIMES (this is not a joke!):

      strncpy(dst, src, n) always over-writes exactly n bytes
      (namely dst[0..(n-1)]), regardless of strlen(src).

A large fraction of lexical calls to strncpy are incorrect;
the code just happens to work "by accident".

First, if there is any overlap between the intervals dst[0..(n-1)]
and src[0..(n-1)] then the result is undefined.  The implementation
of strncpy is allowed to read and write bytes in ANY order: lowest
index first, highest index first, single byte at a time, multiple
bytes at a time, interleaving Read and Write in any order (including
writing into the same byte multiple times, or writing an incorrect
value but correcting it later), etc.  Also, all str* functions are
allowed to fetch beyond src[1+ strlen(src)] as long as there can be
no SIGSEGV; and to store into dst[n] and beyond, as long as there is
no change there.  So any byte that is within the memory words or
cache lines that cover src[] or dst[] is fair game to be included
in a memory operation of strncpy.

Second, if (strlen(src) < n) then strncpy zeroes the remaining bytes
through dst[n-1].

Third, if (strlen(src) >= n) then dst is not NUL terminated.

Recommendation: search all the source code of all the projects
of your entire team/department/company for strncpy, and fix the bugs.

-- 

Re: [Valgrind-users] printing the values of arguments for strcpy(3), memmove(3), ...

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

On 26/01/2021 09:32, Matthias Apitz wrote:

> So far so good. What would have helped me is that vg could print in its
> replacement functions for memmove(3) ... (vg_replace_strmem.c:1270)
> the provided pointers and other args, and as well part of the src
> buffer. For sure vg knows exactly these values to watch the illegal
> memory access.

If the memory is uninitialised then printing it's contents
shouldn't really be useful as they will have no meaning...

Presumably it was partially initialised in this case but it
sounds like quite an edge case and it's easy enough to add
some custom debugging to your code when it does help in cases
like this. I'm not clear if you just printed everything but
you can conditionalise it to only print the failing case:

   if ( VALGRIND_CHECK_MEM_IS_DEFINED( src, n ) )
   {
     fprintf( stderr, "ERROR: %.*s\n", n, src );
   }

if you want to get really clever you can limit it to printing
the valid part:

   const char *fail = VALGRIND_CHECK_MEM_IS_DEFINED( src, n );

   if ( fail )
   {
     fprintf( stderr, "ERROR: %.*s\n", fail - src, src );
   }

Tom

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