valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Semaphore error on Helgrind and Drd?

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

On 25/05/2024 12:29, Paulo Ferreira wrote:
> Error message from Helgrind: 
> 
> $ valgrind --tool=helgrind  ./prog 
> ...
> ==6587== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
> ==6587==    at 0x4850069: sem_wait_WRK (hg_intercepts.c:3155)
> ==6587==    by 0x4851180: sem_wait@* (hg_intercepts.c:3174)
> ==6587==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
> …
> 
> Error message from Drd: 
> 
> $ valgrind --tool=drd --trace-semaphore=yes  ./prog
> ...
> ==6828== [1] sem_wait      0x487f000 value 0 -> 4294967295
> ==6828== Invalid semaphore: semaphore 0x487f000
> ==6828==    at 0x4866C1A: sem_wait_intercept (drd_pthread_intercepts.c:1570)
> ==6828==    by 0x4866C1A: sem_wait@* (drd_pthread_intercepts.c:1578)
> ==6828==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
> ==6828== semaphore 0x487f000 was first observed at:
> ==6828==    at 0x4865A16: sem_open_intercept (drd_pthread_intercepts.c:1527)
> ==6828==    by 0x4865A16: sem_open@* (drd_pthread_intercepts.c:1538)
> ==6828==    by 0x1091D3: main (in /media/sf_antiX/erros/duvida/prog)
> …  
> 
> So the issue seems to be that according to Drd a semaphore that has the value of zero, with a sem_wait() gets decremented to 4294967295. (????????) 
> I have the sample code on the end of this message, and I have tried to run the code on several recent versions of Valgrind (32.3 and others), and on x86-64 using antiX Linux, MX Linux, Ubuntu Linux and FreeBSD. I have also tried ARM 64 bits under Ubuntu, and the behaviour is the same. The sample program seems to work ok. 
> 
> 	pid_t pid = fork(); 
>     if (pid>0) // Parent process
Hi

Semaphores can be used with both threads and processes. I don't think that Valgrind works with semaphores across processes, only threads. 

Regards

Paul

[Valgrind-users] Simple list of functions ever called

[Byron H. <by...@in...>]

For the purposes of studying dead-code elimination in LLVM, I'd like to
generate a simple list of all the functions that are ever called by the
target program. There's no need for any timing or frequency reports or
backtraces or any other details. So far, the best solution I can find
is to filter callgrind output like this:

    grep -E "^c?fn" callgrind/output.raw | cut -d " " -f 2- | grep -Ev
"^0x|^c?fn"

It doesn't seem highly reliable, since I'm just picking out entries by
sort of guessing, then checking the results with gdb (setting a
breakpoint on every symbol not encountered by callgrind). All target
programs are trivial unit tests with rigid, deterministic behavior, but
it would still be nicer to have a more formally defined approach for
extracting a precise set of function symbols for which invocation was
observed during the execution. Thanks in advance for any suggestions.

Byron

Re: [Valgrind-users] Semaphore error on Helgrind and Drd?

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

On 25/05/2024 12:29, Paulo Ferreira wrote:
> Error message from Helgrind: 
> 
> $ valgrind --tool=helgrind  ./prog 
> ...
> ==6587== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
> ==6587==    at 0x4850069: sem_wait_WRK (hg_intercepts.c:3155)
> ==6587==    by 0x4851180: sem_wait@* (hg_intercepts.c:3174)
> ==6587==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
> …
> 
> Error message from Drd: 
> 
> $ valgrind --tool=drd --trace-semaphore=yes  ./prog
> ...
> ==6828== [1] sem_wait      0x487f000 value 0 -> 4294967295
> ==6828== Invalid semaphore: semaphore 0x487f000
> ==6828==    at 0x4866C1A: sem_wait_intercept (drd_pthread_intercepts.c:1570)
> ==6828==    by 0x4866C1A: sem_wait@* (drd_pthread_intercepts.c:1578)
> ==6828==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
> ==6828== semaphore 0x487f000 was first observed at:
> ==6828==    at 0x4865A16: sem_open_intercept (drd_pthread_intercepts.c:1527)
> ==6828==    by 0x4865A16: sem_open@* (drd_pthread_intercepts.c:1538)
> ==6828==    by 0x1091D3: main (in /media/sf_antiX/erros/duvida/prog)
> …  
> 
> So the issue seems to be that according to Drd a semaphore that has the value of zero, with a sem_wait() gets decremented to 4294967295. (????????) 
> I have the sample code on the end of this message, and I have tried to run the code on several recent versions of Valgrind (32.3 and others), and on x86-64 using antiX Linux, MX Linux, Ubuntu Linux and FreeBSD. I have also tried ARM 64 bits under Ubuntu, and the behaviour is the same. The sample program seems to work ok. 
> 
> 	pid_t pid = fork(); 
>     if (pid>0) // Parent process
Hi

Semaphores can be used with both threads and processes. I don't think that Valgrind works with semaphores across processes, only threads. 

Regards

Paul

[Valgrind-users] Semaphore error on Helgrind and Drd?

[Paulo F. <pa...@ke...>]

Error message from Helgrind: 

$ valgrind --tool=helgrind  ./prog 
...
==6587== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
==6587==    at 0x4850069: sem_wait_WRK (hg_intercepts.c:3155)
==6587==    by 0x4851180: sem_wait@* (hg_intercepts.c:3174)
==6587==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
…

Error message from Drd: 

$ valgrind --tool=drd --trace-semaphore=yes  ./prog
...
==6828== [1] sem_wait      0x487f000 value 0 -> 4294967295
==6828== Invalid semaphore: semaphore 0x487f000
==6828==    at 0x4866C1A: sem_wait_intercept (drd_pthread_intercepts.c:1570)
==6828==    by 0x4866C1A: sem_wait@* (drd_pthread_intercepts.c:1578)
==6828==    by 0x109271: main (in /media/sf_antiX/erros/duvida/prog)
==6828== semaphore 0x487f000 was first observed at:
==6828==    at 0x4865A16: sem_open_intercept (drd_pthread_intercepts.c:1527)
==6828==    by 0x4865A16: sem_open@* (drd_pthread_intercepts.c:1538)
==6828==    by 0x1091D3: main (in /media/sf_antiX/erros/duvida/prog)
…  

So the issue seems to be that according to Drd a semaphore that has the value of zero, with a sem_wait() gets decremented to 4294967295. (????????) 
I have the sample code on the end of this message, and I have tried to run the code on several recent versions of Valgrind (32.3 and others), and on x86-64 using antiX Linux, MX Linux, Ubuntu Linux and FreeBSD. I have also tried ARM 64 bits under Ubuntu, and the behaviour is the same. The sample program seems to work ok. 

My thanks to all the Valgrind developers for the wonderful software they created, and I sincerely hope the issue is on my side (between chair and keyboard).

Paulo Ferreira 
======================
#include <stdio.h>
#include <fcntl.h>
#include <semaphore.h>
#include <unistd.h>
#include <sys/wait.h>

#define NUM 10 

int main(void)
{
    int i;
    sem_t *sem1; // First semaphore
    sem_t *sem2; // Second semaphore

    // create, initialize semaphores
    sem1 = sem_open("/semaphore1", O_CREAT,  0600, 0);
    sem2 = sem_open("/semaphore2", O_CREAT,  0600, 1);
	pid_t pid = fork(); 
    if (pid>0) // Parent process
    {
        for (i = 0; i < NUM;  i++)
        {
            sem_wait(sem2); // Lock the semaphore
            write(1, "a\n", 2);
            sem_post(sem1); // Release the semaphore lock
        }
        wait(NULL);
    }
    else // Child process
    {
        for (i = 0; i < NUM; i++)
        {   
		    sem_wait(sem1); // Lock the semaphore
            write(1, "b\n", 2);
            sem_post(sem2); // Release the semaphore lock
        }
    }


	// Close the Semaphores
    sem_close(sem1);
    sem_unlink("/semaphore1");
    sem_close(sem2);
    sem_unlink("/semaphore2");
    return 0;
}
==========================

 

    

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

[Simon S. <sim...@gn...>]

That's

clang version 18.1.4
Target: aarch64-unknown-linux-android24

No flags set at all (other than --enable-lto). Checking for warning flags noted in config.log:

CFLAGS_MPI='-g -O -fno-omit-frame-pointer -Wall -fpic'
FLAG_W_CAST_ALIGN='-Wcast-align'
FLAG_W_CAST_QUAL='-Wcast-qual'
FLAG_W_EMPTY_BODY='-Wempty-body'
FLAG_W_ENUM_CONVERSION='-Wenum-conversion'
FLAG_W_EXTRA='-Wextra'
FLAG_W_FORMAT='-Wformat'
FLAG_W_FORMAT_SECURITY='-Wformat-security'
FLAG_W_IGNORED_QUALIFIERS='-Wignored-qualifiers'
FLAG_W_NO_ATTRIBUTES='-Wno-attributes'
FLAG_W_NO_BUILTIN_MEMCPY_CHK_SIZE='-Wno-builtin-memcpy-chk-size'
FLAG_W_NO_EXPANSION_TO_DEFINED='-Wno-expansion-to-defined'
FLAG_W_NO_FORMAT_OVERFLOW='-Wno-format-overflow'
FLAG_W_NO_FORTIFY_SOURCE='-Wno-fortify-source'
FLAG_W_NO_FREE_NONHEAP_OBJECT='-Wno-free-nonheap-object'
FLAG_W_NO_INCOMPATIBLE_POINTER_TYPES_DISCARDS_QUALIFIERS='-Wno-incompatible-pointer-types-discards-qualifiers'
FLAG_W_NO_INFINITE_RECURSION='-Wno-infinite-recursion'
FLAG_W_NO_MEMSET_TRANSPOSED_ARGS='-Wno-memset-transposed-args'
FLAG_W_NO_MISMATCHED_NEW_DELETE='-Wno-mismatched-new-delete'
FLAG_W_NO_NONNULL='-Wno-nonnull'
FLAG_W_NO_NON_POWER_OF_TWO_ALIGNMENT='-Wno-non-power-of-two-alignment'
FLAG_W_NO_OVERFLOW='-Wno-overflow'
FLAG_W_NO_POINTER_SIGN='-Wno-pointer-sign'
FLAG_W_NO_SIGN_COMPARE='-Wno-sign-compare'
FLAG_W_NO_STATIC_LOCAL_IN_INLINE='-Wno-static-local-in-inline'
FLAG_W_NO_SUSPICIOUS_BZERO='-Wno-suspicious-bzero'
FLAG_W_NO_UNINITIALIZED='-Wno-uninitialized'
FLAG_W_NO_UNUSED_BUT_SET_VARIABLE='-Wno-unused-but-set-variable'
FLAG_W_NO_UNUSED_FUNCTION='-Wno-unused-function'
FLAG_W_NO_UNUSED_VARIABLE='-Wno-unused-variable'
FLAG_W_WRITE_STRINGS='-Wwrite-strings'

Simon

Am 27. April 2024 14:05:59 MESZ schrieb Paul Floyd via Valgrind-users <val...@li...>:
>
>
>On 25-04-24 19:09, Simon Sobisch wrote:
>> 
>> 
>> Am 25.04.2024 um 20:55 schrieb Paul Floyd via Valgrind-users:
>>> 
>>> On 25-04-24 14:39, Simon Sobisch wrote:
>>> 
>>>> 3. compile warnings with clang on arm64 (in multiple files/positions with different arguments to the macros CALL_FN_W_W, CALL_FN_W_WW, CALL_FN_W_WWW and CALL_FN_W_WWWW):
>>> 
>>> For the arm64 warnings, what OS were you usung?
>> 
>> That was Android running within Termux.
>
>Which version of clang is that using? And does it use any extra compiler flags?
>
>FreeBSD 14 with clang 16 (and 18) only produces a couple of warnings:
>
>
>integer.c:30:21: warning: unused function 'randUChar' [-Wunused-function]
>
>and
>
>arm64_features.c:28:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
>
>(well, they did, I just fixed them).
>
>I also tried adding -Winline-asm, still no warnings.
>
>A+
>Paul
>
>
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

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

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

On 25-04-24 19:09, Simon Sobisch wrote:
> 
> 
> Am 25.04.2024 um 20:55 schrieb Paul Floyd via Valgrind-users:
>>
>> On 25-04-24 14:39, Simon Sobisch wrote:
>>
>>> 3. compile warnings with clang on arm64 (in multiple files/positions 
>>> with different arguments to the macros CALL_FN_W_W, CALL_FN_W_WW, 
>>> CALL_FN_W_WWW and CALL_FN_W_WWWW):
>>
>> For the arm64 warnings, what OS were you usung?
> 
> That was Android running within Termux.

Which version of clang is that using? And does it use any extra compiler 
flags?

FreeBSD 14 with clang 16 (and 18) only produces a couple of warnings:


integer.c:30:21: warning: unused function 'randUChar' [-Wunused-function]

and

arm64_features.c:28:1: warning: non-void function does not return a 
value in all control paths [-Wreturn-type]

(well, they did, I just fixed them).

I also tried adding -Winline-asm, still no warnings.

A+
Paul

[Valgrind-users] Valgrind-3.23.0 is available

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

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

See the release notes below for details of changes.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

* --track-fds=yes will now also warn about double closing of file
  descriptors. Printing the context where the file descriptor was
  originally opened and where it was previously closed.

* --track-fds=yes also produces "real" errors now which can be
  suppressed and work with --error-exitcode. When combined with
  --xml the xml-output now also includes FdBadClose and FdNotClosed
  error kinds (see docs/internals/xml-output-protocol5.txt).

* The option --show-error-list=no|yes now accepts a new value all.
  This indicates to also print the suppressed errors.
  This is useful to analyse which errors are suppressed by which
  suppression entries.
  The valgrind monitor command 'v.info all_errors' similarly now
  accepts a new optional argument 'also_suppressed' to show
  all errors including the suppressed errors.

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

* Added ARM64 support for FreeBSD.

* ARM64 now supports dotprod instructions (sdot/udot).

* AMD64 better supports code build with -march=x86-64-v3.
  fused-multiple-add instructions (fma) are now emulated more
  accurately. And memcheck now handles __builtin_strcmp using 128/256
  bit vectors with sse4.1, avx/avx2.

* S390X added support for NNPA (neural network processing assist)
  facility vector instructions VCNF, VCLFNH, VCFN, VCLFNL, VCRNF and
  NNPA (z16/arch14).

* X86 recognizes new binutils-2.42 nop patterns.

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

* The none tool now also supports xml output.

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


283429  ARM leak checking needs CLEAR_CALLER_SAVED_REGS
281059  Cannot connect to Oracle using valgrind
328563  make track-fds support xml output
362680  --error-exitcode not honored when file descriptor leaks are found
369723  __builtin_longjmp not supported in clang/llvm on Android arm64 target
390269  unhandled amd64-darwin syscall: unix:464 (openat_nocancel)
401284  False positive "Source and destination overlap in strncat"
428364  Signals inside io_uring_enter not handled
437790  valgrind reports "Conditional jump or move depends on uninitialised
        value" in memchr of macOS 10.12-10.15
460616  disInstr(arm64): unhandled instruction 0x4E819402 (dotprod/ASIMDDP)
463458  memcheck/tests/vcpu_fnfns fails when glibc is built for x86-64-v3
463463  none/tests/amd64/fma fails when executed on a x86-64-v3 system
466762  Add redirs for C23 free_sized() and free_aligned_sized()
466884  Missing writev uninit padding suppression for _XSend
471036  disInstr_AMD64: disInstr miscalculated next %rip on RORX imm8, m32/64, r32/6
471222  support tracking of file descriptors being double closed
474160  If errors-for-leak-kinds is specified, exit-on-first-error should only exit
        on one of the listed errors.
475498  Add reallocarray wrapper
476025  Vbit expected test results for Iop_CmpGT64Ux2 are wrong
476320  Build failure with GCC
476331  clean up generated/distributed filter scripts
476535  Difference in allocation size for massif/tests/overloaded-new between
        clang++/libc++ and g++/libstdc++
476548  valgrind 3.22.0 fails on assertion when loading debuginfo file
        produced by mold
476708  valgrind-monitor.py regular expressions should use raw strings
476780  Extend strlcat and strlcpy wrappers to GNU libc
476787  Build of Valgrind 3.21.0 fails when SOLARIS_PT_SUNDWTRACE_THRP is
        defined
476887  WARNING: unhandled amd64-freebsd syscall: 578
477198  Add fchmodat2 syscall on linux
477628  Add mremap support for Solaris
477630  Include ucontext.h rather than sys/ucontext.h in Solaris sources
477719  vgdb incorrectly replies to qRcmd packet
478211  Redundant code for vgdb.c and Valgrind core tools
478624  Valgrind incompatibility with binutils-2.42 on x86 with new nop patterns
        (unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26
478837  valgrind fails to read debug info for rust binaries
479041  Executables without RW sections do not trigger debuginfo reading
480052  WARNING: unhandled amd64-freebsd syscall: 580
480126  Build failure on Raspberry Pi 5 / OS 6.1.0-rpi7-rpi-v8
480405  valgrind 3.22.0 "m_debuginfo/image.c:586 (set_CEnt):
        Assertion '!sr_isError(sr)' failed."
480488  Add support for FreeBSD 13.3
480706  Unhandled syscall 325 (mlock2)
481127  amd64: Implement VFMADD213 for Iop_MAddF32
481131  [PATCH] x86 regtest: fix clobber lists in generated asm statements
481676  Build failure on Raspberry Pi 5 Ubuntu 23.10 with clang
481874  Add arm64 support for FreeBSD
483786  Incorrect parameter indexing in FreeBSD clock_nanosleep syscall wrapper
484002  Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
484426  aarch64: 0.5 gets rounded to 0
484480  False positives when using sem_trywait
484935  [patch] Valgrind reports false "Conditional jump or move depends on
        uninitialised value" errors for aarch64 signal handlers
485148  vfmadd213ss instruction is instrumented incorrectly (the remaining
        part of the register is cleared instead of kept unmodified)
485487  glibc built with -march=x86-64-v3 does not work due to ld.so strcmp
485778  Crash with --track-fds=all and --gen-suppressions=all
n-i-bz  Add redirect for memccpy

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

(3.23.0.RC1: 19 Apr 2024)
(3.23.0.RC2: 24 Apr 2024)

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

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

On 24-04-24 23:33, Mark Wielaard wrote:
> An RC2 tarball for 3.23.0 is now available at


FreeBSD amd64 and arm64 both still fine.

A+
Paul

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

[Simon S. <sim...@gn...>]

Am 25.04.2024 um 20:55 schrieb Paul Floyd via Valgrind-users:
> 
> On 25-04-24 14:39, Simon Sobisch wrote:
>
>> 3. compile warnings with clang on arm64 (in multiple files/positions 
>> with different arguments to the macros CALL_FN_W_W, CALL_FN_W_WW, 
>> CALL_FN_W_WWW and CALL_FN_W_WWWW):
> 
> For the arm64 warnings, what OS were you usung?

That was Android running within Termux.

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

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

On 25-04-24 08:50, Simon Sobisch wrote:
> I've compiled and tried to run the RC2 on some environments, using
> 
> 1. Find just a minor patch for configure.ac to improve help output and 
> keep the style of the file (two missing spaces visible in "configure 
> --help"; tabs/line breaks).
> 
> 2. One thing that _may_ be an old issue: all the make targets check, 
> regtest and perf fail because of missing g++ on building "bug464969", 
> while configure and make pass.

> 
> 3. "make regtest" fails in my out-of-tree build (where "make check" 
> executed without errors)
> 
> ../gdbserver_tests/make_local_links /usr/bin/gdb
> if /usr/bin/perl tests/vg_regtest gdbserver_tests memcheck cachegrind 
> callgrind helgrind drd massif dhat lackey none exp-bbv ; then \
>     tests/post_regtest_checks /home/build/valgrind-3.23.0.RC2/build/.. 
> gdbserver_tests memcheck cachegrind callgrind helgrind drd massif dhat 
> lackey none exp-bbv; \
> else \
>     tests/post_regtest_checks /home/build/valgrind-3.23.0.RC2/build/.. 
> gdbserver_tests memcheck cachegrind callgrind helgrind drd massif dhat 
> lackey none exp-bbv; \
>     false; \
> fi
> sh: 0: cannot open 
> /home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
> sh: 0: cannot open 
> /home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
> sh: 0: cannot open 
> /home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
> sh: 0: cannot open 
> /home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
> -- Running  tests in memcheck/tests/linux ------------------------------
> vg_regtest: `./filter_stderr' not found or not a file (.)
> /bin/bash: line 4: tests/post_regtest_checks: No such file or directory
> make: *** [Makefile:1442: regtest] Error 1
> 
> 
> 4. "make perf" outputs
> == 0 programs, 0 timings =================

Hi

I'll apply the configure patch after the release.

Not having a C++ compiler. I can just about imagine someone building and 
using Valgrind without a C++ compiler - in some situations it might make 
automatic package building faster. Is there any benefit to being able to 
run only the non-C++ testcases?

It's a while since I tried an out of tree build. There is a bugzilla 
item for that https://bugs.kde.org/show_bug.cgi?id=333628

What platform did you use for "make perf"?

A+
Paul

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

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

On 25-04-24 14:39, Simon Sobisch wrote:
> 1. Several failing tests because of sed and ps usage. With
>
> 2.  Two failing tests on Debian with AMD Ryzen:

> 3. compile warnings with clang on arm64 (in multiple files/positions 
> with different arguments to the macros CALL_FN_W_W, CALL_FN_W_WW, 
> CALL_FN_W_WWW and CALL_FN_W_WWWW):



Hi

Thanks for the tests.

sed, ps etc. I don't think that it's worth adding checks but we should 
add something to README_DEVELOPERS. It's a similar situation on FreeBSD 
and Illumos, documented in their respective READMEs.

Regtest fails. stime is deprecated, but that shouldn't change things.
The permission messages - I'll see if I can reproduce on another machine.

For the arm64 warnings, what OS were you usung?

The last two warnings I'll deal with after the release.

A+
Paul

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

[Carl L. <ce...@li...>]

Mark:

RC2 fixes a number of failures from RC1.  I think it RC2 is good to go.

Power 10
memcheck/tests/linux/rfcomm              (stderr)    Also failed for valgrind 3.22.0

Power 9
memcheck/tests/leak_cpp_interior         (stderr)    Also failed for valgrind 3.22.0
memcheck/tests/linux/rfcomm              (stderr)    Also failed for valgrind 3.22.0
memcheck/tests/linux/sys-execveat        (stderr)    Also failed for valgrind 3.22.0

Power8LE
memcheck/tests/leak_cpp_interior         (stderr)    Also failed for valgrind 3.22.0                      
memcheck/tests/linux/rfcomm              (stderr)    Also failed for valgrind 3.22.0                           
memcheck/tests/linux/sys-execveat        (stderr)    Also failed for valgrind 3.22.0

Power8BE
memcheck/tests/leak_cpp_interior         (stderr)    Also failed for valgrind 3.22.0
none/tests/socket_close                  (stderr)    Didn't see this one fail for 3.22.0 but it did
                                                     for some of the other platforms.  So maybe it
                                                     is a little noisy.  I don't think it is an issue.

Ship it!

                           Carl 

On 4/24/24 16:33, Mark Wielaard wrote:
> An RC2 tarball for 3.23.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2
> (md5sum = c1540fb2d48648666f1479d3e44154be)
> (sha1sum = 85438bfae1e03a42cacda0a7a4071c49eaa97f96)
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2.asc
> 
> Changes since RC1
> 
> Andreas Arnez (1):
>   s390x: Improve operand names in trackers for PRNO
> 
> Mark Wielaard (11):
>   32 bit new_delete_mismatch_size and sized_aligned_new_delete_misaligned .exp
>   Add new .exp-32 files to memcheck/tests/Makefile.am EXTRA_DIST
>   filter out in /absolute/path in drd/tests stderr filter
>   Filter away "main" differences in filter_fdleak
>   VG_(show_open_fds) Only emit empty line when not creating xml output
>   Add dl_new_hash suppression to drd/tests/std_thread2.supp
>   Add another drd/tests/bar_bad exp variant.
>   Add new bar_bad exp files to drd/tests/Makefile.am (EXTRA_DIST).
>   Add prereqs for tests using python 3.9+
>   glibc-2.X-helgrind.supp.in: Also recognize variants on gethostbyname2_r
>   Set version to 3.23.0-RC2
> 
> Paul Floyd (6):
>   FreeBSD suppression: add a suppression for __swbuf seen on arm64
>   FreeBSD suppression: reachable for setlocale
>   FreeBSD suppressions: yet more reachables
>   FreeBSD suppression: puts reachable
>   FreeBSD syswrap: wrong length for __sysctlbyname(name)
>   FreeBSD syscall: add wrapper for kcmp
> 
> 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 will happen on
> Friday 26 April.
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[Simon S. <sim...@gn...>]

1. Several failing tests because of sed and ps usage. With

sed --version
This is not GNU sed version 4.0
BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary.

There are a bunch of

	sed: unsupported command ,

messages during "make regtest" so the result is not usable

similar with ps
BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary.

raising
	ps: unrecognized option: p


Ideally configure would check for the used options and raise a warning 
that the tests cannot be run, "make regtest" and friends could run a 
pre-target that tries to execute those tools as well.


2.  Two failing tests on Debian with AMD Ryzen:

== 895 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 
0 stdoutB failures, 0 post failures ==
memcheck/tests/x86-linux/scalar          (stderr)
none/tests/scripts/shell                 (stderr)



--- scalar.stderr.exp   2024-04-25 00:46:46.000000000 +0200
+++ scalar.stderr.out   2024-04-25 13:18:57.456992272 +0200
@@ -224,7 +224,7 @@
     ...
     by 0x........: main (scalar.c:97)
   Address 0x........ is on thread 1's stack
- in frame #1, created by main (scalar.c:29)
+ in frame #2, created by main (scalar.c:29)

  Syscall param execve(argv[0]) points to unaddressable byte(s)
     ...
@@ -255,7 +255,7 @@
     ...
     by 0x........: main (scalar.c:100)
   Address 0x........ is on thread 1's stack
- in frame #1, created by main (scalar.c:29)
+ in frame #2, created by main (scalar.c:29)

  Syscall param execve(envp[i]) points to unaddressable byte(s)
     ...
@@ -404,3828 +404,4 @@
  -----------------------------------------------------
   24:         __NR_getuid 0s 0m
  -----------------------------------------------------
------------------------------------------------------
- 25:          __NR_stime n/a
------------------------------------------------------
[more]
-
+scalar: scalar.c:152: main: Assertion `-1 != res' failed.

and

--- shell.stderr.exp    2024-04-25 00:46:46.000000000 +0200
+++ shell.stderr.out    2024-04-25 13:26:20.796944128 +0200
@@ -1,8 +1,8 @@
-./shell: ./x86/: is a directory
-./shell: ./shell.vgtest: Permission denied
+./shell: 10: ./x86/: Permission denied
+./shell: 13: ./shell.vgtest: Permission denied
  execve(0x........(./shell_badinterp), 0x........, 0x........) failed, 
errno 2
  EXEC FAILED: I can't recover from execve() failing, so I'm dying.
  Add more stringent tests in PRE(sys_execve), or work out how to recover.
-./shell: ./shell_binaryfile: cannot execute binary file
-./shell: ./shell_nosuchfile: No such file or directory
-./shell: shell_nosuchfile: command not found
+./shell: 19: ./shell_binaryfile: Exec format error
+./shell: 22: ./shell_nosuchfile: not found
+./shell: 25: shell_nosuchfile: Permission denied


3. compile warnings with clang on arm64 (in multiple files/positions 
with different arguments to the macros CALL_FN_W_W, CALL_FN_W_WW, 
CALL_FN_W_WWW and CALL_FN_W_WWWW):

warning: inline asm clobber list contains reserved registers: X18 
[-Winline-asm]
    74 |    CALL_FN_W_W(ret, fn, guard);
       |    ^
../include/valgrind.h:4339:10: note: expanded from macro 'CALL_FN_W_W'
  4339 |          VALGRIND_ALIGN_STACK                                     \
       |          ^
../include/valgrind.h:4304:7: note: expanded from macro 
'VALGRIND_ALIGN_STACK'
  4304 |       "mov x21, sp\n\t"                    \
       |       ^
note: Reserved registers on the clobber list may not be preserved across 
the asm statement, and clobbering them may lead to undefined behaviour.
../include/valgrind.h:4339:10: note: expanded from macro 'CALL_FN_W_W'
  4339 |          VALGRIND_ALIGN_STACK                                     \
       |          ^
../include/valgrind.h:4304:7: note: expanded from macro 
'VALGRIND_ALIGN_STACK'
  4304 |       "mov x21, sp\n\t"                    \
       |       ^

together with

m_coredump/coredump-elf.c:775:17: warning: variable 'name' set but not 
used [-Wunused-but-set-variable]
   775 |    const HChar* name;
       |                 ^
m_debuginfo/readdwarf3.c:3121:14: warning: variable 'n_attrs' set but 
not used [-Wunused-but-set-variable]
  3121 |       Int    n_attrs     = 0;



BTW - FYI: no failures on Rocky9 with some Intel processor

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

[Simon S. <sim...@gn...>]

I've compiled and tried to run the RC2 on some environments, using

mkdir build
cd build
../configure --enable-lto
make -j8
make -j8 check
make regtest
make perf

and think I've found some things related to the build system (and/or 
documentation).


1. Find just a minor patch for configure.ac to improve help output and 
keep the style of the file (two missing spaces visible in "configure 
--help"; tabs/line breaks).


2. One thing that _may_ be an old issue: all the make targets check, 
regtest and perf fail because of missing g++ on building "bug464969", 
while configure and make pass.


The configure script notes a bunch of "not working" parts related to CXX 
as it tests for the appropriate g++ but even if it doesn't find any 
still do all CXX tests:

configure:5587: checking for g++
configure:5622: result: no
configure:5587: checking for c++
configure:5622: result: no
configure:5587: checking for gpp
configure:5622: result: no
--
configure:5587: checking for clang++
configure:5622: result: no
configure:5646: checking for C++ compiler version
configure:5655: g++ --version >&5
../configure: eval: line 5657: g++: Permission denied
configure:5666: $? = 127
configure:5655: g++ -v >&5
../configure: eval: line 5657: g++: Permission denied
configure:5666: $? = 127
configure:5655: g++ -V >&5
../configure: eval: line 5657: g++: Permission denied
configure:5666: $? = 127
configure:5655: g++ -qversion >&5
../configure: eval: line 5657: g++: Permission denied
configure:5666: $? = 127
configure:5670: checking whether the compiler supports GNU C++
configure:5690: g++ -c   conftest.cpp >&5
../configure: eval: line 2083: g++: Permission denied
configure:5690: $? = 127
configure:5711: checking whether g++ accepts -g
configure:5732: g++ -c -g  conftest.cpp >&5
../configure: eval: line 2083: g++: Permission denied
configure:5748: g++ -c   conftest.cpp >&5
../configure: eval: line 2083: g++: Permission denied
configure:5748: $? = 127
configure:5796: checking for g++ option to enable C++11 features
configure:5811: g++  -c   conftest.cpp >&5
../configure: eval: line 2083: g++: Permission denied
[more to come]
configure:19286: checking if g++ supports __sync_add_and_fetch
configure:19313: g++ -o conftest -m64   conftest.cpp  >&5
../configure: eval: line 2424: g++: Permission denied


As "make" did not fail I deduce that CXX is only optional, in this case 
it would be useful to:

* skip all CXX related tests in configure if it isn't found as an
   executable
* skip all g++ related tests in "make check", "make regtest", "make perf".


3. "make regtest" fails in my out-of-tree build (where "make check" 
executed without errors)

../gdbserver_tests/make_local_links /usr/bin/gdb
if /usr/bin/perl tests/vg_regtest gdbserver_tests memcheck cachegrind 
callgrind helgrind drd massif dhat lackey none exp-bbv ; then \
    tests/post_regtest_checks /home/build/valgrind-3.23.0.RC2/build/.. 
gdbserver_tests memcheck cachegrind callgrind helgrind drd massif dhat 
lackey none exp-bbv; \
else \
    tests/post_regtest_checks /home/build/valgrind-3.23.0.RC2/build/.. 
gdbserver_tests memcheck cachegrind callgrind helgrind drd massif dhat 
lackey none exp-bbv; \
    false; \
fi
sh: 0: cannot open 
/home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
sh: 0: cannot open 
/home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
sh: 0: cannot open 
/home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
sh: 0: cannot open 
/home/build/valgrind-3.23.0.RC2/build/tests/platform_test: No such file
-- Running  tests in memcheck/tests/linux ------------------------------
vg_regtest: `./filter_stderr' not found or not a file (.)
/bin/bash: line 4: tests/post_regtest_checks: No such file or directory
make: *** [Makefile:1442: regtest] Error 1


4. "make perf" outputs
== 0 programs, 0 timings =================


Kind regards and thank you for improving valgrind!
Simon


Am 25.04.2024 um 01:33 schrieb Mark Wielaard:
> An RC2 tarball for 3.23.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2
> (md5sum = c1540fb2d48648666f1479d3e44154be)
> (sha1sum = 85438bfae1e03a42cacda0a7a4071c49eaa97f96)
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2.asc
> 
> Changes since RC1
> 
> Andreas Arnez (1):
>    s390x: Improve operand names in trackers for PRNO
> 
> Mark Wielaard (11):
>    32 bit new_delete_mismatch_size and sized_aligned_new_delete_misaligned .exp
>    Add new .exp-32 files to memcheck/tests/Makefile.am EXTRA_DIST
>    filter out in /absolute/path in drd/tests stderr filter
>    Filter away "main" differences in filter_fdleak
>    VG_(show_open_fds) Only emit empty line when not creating xml output
>    Add dl_new_hash suppression to drd/tests/std_thread2.supp
>    Add another drd/tests/bar_bad exp variant.
>    Add new bar_bad exp files to drd/tests/Makefile.am (EXTRA_DIST).
>    Add prereqs for tests using python 3.9+
>    glibc-2.X-helgrind.supp.in: Also recognize variants on gethostbyname2_r
>    Set version to 3.23.0-RC2
> 
> Paul Floyd (6):
>    FreeBSD suppression: add a suppression for __swbuf seen on arm64
>    FreeBSD suppression: reachable for setlocale
>    FreeBSD suppressions: yet more reachables
>    FreeBSD suppression: puts reachable
>    FreeBSD syswrap: wrong length for __sysctlbyname(name)
>    FreeBSD syscall: add wrapper for kcmp
> 
> 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 will happen on
> Friday 26 April.
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

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

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

An RC2 tarball for 3.23.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2
(md5sum = c1540fb2d48648666f1479d3e44154be)
(sha1sum = 85438bfae1e03a42cacda0a7a4071c49eaa97f96)
https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC2.tar.bz2.asc

Changes since RC1

Andreas Arnez (1):
  s390x: Improve operand names in trackers for PRNO

Mark Wielaard (11):
  32 bit new_delete_mismatch_size and sized_aligned_new_delete_misaligned .exp
  Add new .exp-32 files to memcheck/tests/Makefile.am EXTRA_DIST
  filter out in /absolute/path in drd/tests stderr filter
  Filter away "main" differences in filter_fdleak
  VG_(show_open_fds) Only emit empty line when not creating xml output
  Add dl_new_hash suppression to drd/tests/std_thread2.supp
  Add another drd/tests/bar_bad exp variant.
  Add new bar_bad exp files to drd/tests/Makefile.am (EXTRA_DIST).
  Add prereqs for tests using python 3.9+
  glibc-2.X-helgrind.supp.in: Also recognize variants on gethostbyname2_r
  Set version to 3.23.0-RC2

Paul Floyd (6):
  FreeBSD suppression: add a suppression for __swbuf seen on arm64
  FreeBSD suppression: reachable for setlocale
  FreeBSD suppressions: yet more reachables
  FreeBSD suppression: puts reachable
  FreeBSD syswrap: wrong length for __sysctlbyname(name)
  FreeBSD syscall: add wrapper for kcmp

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 will happen on
Friday 26 April.

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

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

> On 22 Apr 2024, at 20:40, Carl Love via Valgrind-users <val...@li...> wrote:
> 
> Mark:
> 
> The PowerPC test results for Valgrind 3.23.0.RC1
> 
> -----------------------------------------------------------
> Power 10, Fedora release 38 :
> 
>  memcheck/tests/linux/rfcomm              (stderr)  also fails for valgrind 3.21.0
>  helgrind/tests/getaddrinfo               (stderr)  did not fail for valgrind 3.21.0

This probably needs some suppressions. On other platforms (and libcs) getaddrinfo uses a load of non-pthread locks causing a lot of noise.

A+
Paul

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

[Carl L. <ce...@li...>]

Mark:


On 4/23/24 05:21, Mark Wielaard wrote:
> Hi Carl,
> 
> On Mon, 2024-04-22 at 11:40 -0700, Carl Love wrote:
>> The PowerPC test results for Valgrind 3.23.0.RC1
> Thanks. Looks fairly good overall. I haven't studied the rest, but ...
> 
>>   none/tests/fdleak_ipv4                   (stderr)  New failure, did not fail for valgrind 3.22.0
>>   none/tests/file_dclose                   (stderr)  New failure, did not fail for valgrind 3.22.0
>>   none/tests/socket_close                  (stderr)  New failure, did not fail for valgrind 3.22.0
> These are new tests in 3.23.0 and for some reason they "main" part of
> the stacktrace is slightly different on different systems. I tried to
> work around that with the following commit:

Agreed, I think things look good.  I don't see the three new failures as something that should block the release.  I am ok with RC1.

                       Carl 

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

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

Hi Carl,

On Mon, 2024-04-22 at 11:40 -0700, Carl Love wrote:
> The PowerPC test results for Valgrind 3.23.0.RC1

Thanks. Looks fairly good overall. I haven't studied the rest, but ...

>   none/tests/fdleak_ipv4                   (stderr)  New failure, did not fail for valgrind 3.22.0
>   none/tests/file_dclose                   (stderr)  New failure, did not fail for valgrind 3.22.0
>   none/tests/socket_close                  (stderr)  New failure, did not fail for valgrind 3.22.0

These are new tests in 3.23.0 and for some reason they "main" part of
the stacktrace is slightly different on different systems. I tried to
work around that with the following commit:

commit 04d30049bf9b4ae14262a50e8a16442e1edf75f8
Author: Mark Wielaard <ma...@kl...>
Date:   Tue Apr 23 14:14:33 2024 +0200

  Filter away "main" differences in filter_fdleak
    
  Stack traces showing where fds were created show some differences in
  the "main" function, different line numbers, or (in binary) or (below
  main). Since the precise location of the original call in the main
  function isn't the goal of these tests just filer them all out and
  replace them with a simple "main".

Which should be part of RC2 to be published tomorrow.

Cheers,

Mark

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

[Carl L. <ce...@li...>]

Mark:

The PowerPC test results for Valgrind 3.23.0.RC1

-----------------------------------------------------------
Power 10, Fedora release 38 :

  memcheck/tests/linux/rfcomm              (stderr)  also fails for valgrind 3.21.0
  helgrind/tests/getaddrinfo               (stderr)  did not fail for valgrind 3.21.0
  drd/tests/std_thread2                    (stderr)  did not fail for valgrind 3.21.0
  none/tests/socket_close                  (stderr)  did not fail for valgrind 3.21.0

  Note the following failed in valgrind 3.22.0: 

  memcheck/tests/bug340392                 (stderr)
  memcheck/tests/linux/rfcomm              (stderr)

  but do not fail for Valgrind-3.23.0.RC1 

----------------------------------------------------------------
Power 9LE, Ubuntu 20.04.6 LTS 

  Valgrind-3.23.0.RC1 failures:

  memcheck/tests/leak_cpp_interior         (stderr)   Also failed for valgrind 3.22.0 
  memcheck/tests/linux/rfcomm              (stderr)   Also failed for valgrind 3.22.0  
  memcheck/tests/linux/sys-execveat        (stderr)   Also failed for valgrind 3.22.0 
  none/tests/fdleak_ipv4                   (stderr)   New failure, did not fail for valgrind 3.22.0
  none/tests/socket_close                  (stderr)   New failure, did not fail for valgrind 3.22.0

  Note the following failed in valgrind 3.22.0:

  memcheck/tests/bug340392                 (stderr)
  memcheck/tests/leak_cpp_interior         (stderr) 

  but do not fail for Valgrind-3.23.0.RC1 

----------------------------------------------------------------
Power 8LE, Ubuntu 20.04.6 LTS

  Valgrind-3.23.0.RC1 failures:

  memcheck/tests/leak_cpp_interior         (stderr)   Also failed for valgrind 3.22.0                        
  memcheck/tests/linux/rfcomm              (stderr)   Also failed for valgrind 3.22.0                              
  memcheck/tests/linux/sys-execveat        (stderr)   New failure, did not fail for valgrind 3.22.0                      
  none/tests/fdleak_ipv4                   (stderr)   New failure, did not fail for valgrind 3.22.0                                
  none/tests/socket_close                  (stderr)   New failure, did not fail for valgrind 3.22.0  

  Note the two failures from the previous valgrind -3.22.0
         
  memcheck/tests/bug340392                 (stderr)                               
  memcheck/tests/linux/sys-execveat        (stderr) 

  but do not fail for Valgrind-3.23.0.RC1 

--------------------------------------------------------------------

Power 8BE, Red Hat Enterprise Linux Server release 7.9 (Maipo)

  Valgrind-3.23.0.RC1 failures:

  memcheck/tests/leak_cpp_interior         (stderr)  Also failed for valgrind 3.22.0
  none/tests/fdleak_ipv4                   (stderr)  New failure, did not fail for valgrind 3.22.0
  none/tests/file_dclose                   (stderr)  New failure, did not fail for valgrind 3.22.0
  none/tests/socket_close                  (stderr)  New failure, did not fail for valgrind 3.22.0
 
  Note the failure from the previous valgrind -3.22.0

  memcheck/tests/bug340392                 (stderr)

  do not fail for Valgrind-3.23.0.RC1 

--------------------------------------------------------------------------

So, seeing very consistent results across distros and PowerPC processor versions.

The diff for the four failures on Power 10 are:  

  memcheck/tests/linux/sys-execveat:

more rfcomm.stderr.diff
--- rfcomm.stderr.exp	2021-01-21 10:09:33.000000000 -0500
+++ rfcomm.stderr.out	2024-04-22 11:33:22.949419105 -0400
@@ -2,7 +2,7 @@
    ...
    by 0x........: main (rfcomm.c:53)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:45)
 
@@ -10,7 +10,7 @@
    ...
    by 0x........: main (rfcomm.c:53)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:45)
 
@@ -18,7 +18,7 @@
    ...
    by 0x........: main (rfcomm.c:53)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:45)
 
@@ -26,7 +26,7 @@
    ...
    by 0x........: main (rfcomm.c:59)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:58)
 
@@ -34,7 +34,7 @@
    ...
    by 0x........: main (rfcomm.c:59)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:58)
 
@@ -42,7 +42,7 @@
    ...
    by 0x........: main (rfcomm.c:63)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:58)
 
@@ -50,7 +50,7 @@
    ...
    by 0x........: main (rfcomm.c:63)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:58)
 
@@ -58,7 +58,7 @@
    ...
    by 0x........: main (rfcomm.c:67)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:58)

----------------------------------------------------------------------

helgrind/tests/getaddrinfo:

 more getaddrinfo.stderr.diff
--- getaddrinfo.stderr.exp	2023-05-16 07:21:42.000000000 -0400
+++ getaddrinfo.stderr.out	2024-04-22 11:36:08.969379829 -0400
@@ -0,0 +1,31 @@
+---Thread-Announcement------------------------------------------
+
+Thread #x was created
+   ...
+   by 0x........: pthread_create@* (hg_intercepts.c:...)
+   by 0x........: main (getaddrinfo.c:33)
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+   ...
+ Address 0x........ is in the Text segment of /usr/lib64/libnss_resolve.so.2
+   ...
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+   ...
+ Address 0x........ is in the Text segment of /usr/lib64/libnss_resolve.so.2
+   ...
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+   ...
+ Address 0x........ is in the Text segment of /usr/lib64/libnss_resolve.so.2
+   ...
+


-------------------------------------------------------------------------
drd/tests/std_thread2:

more std_thread2.stderr.diff
--- std_thread2.stderr.exp	2021-01-21 10:09:33.000000000 -0500
+++ std_thread2.stderr.out	2024-04-22 11:39:24.519333567 -0400
@@ -1,9 +1,14 @@
 
 Thread 2:
+Conflicting load by thread 2 at 0x........ size 8
+   at 0x........: _dl_new_hash (dl-new-hash.h:90)
+   by 0x........: _dl_lookup_symbol_x (dl-lookup.c:757)
+Allocation context: Data section of /usr/lib64/ld64.so.2
+
 Conflicting store by thread 2 at 0x........ size 4
    at 0x........: main::LAMBDA::operator()() const (std_thread2.cpp:21)
 Allocation context: BSS section of std_thread2
 
 Done.
 
-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 0 from 0)

------------------------------------------------------------------

none/tests/socket_close:

 more socket_close.stderr.diff
--- socket_close.stderr.exp	2024-04-18 09:59:55.000000000 -0400
+++ socket_close.stderr.out	2024-04-22 11:41:09.189308805 -0400
@@ -10,4 +10,4 @@
  Originally opened
    at 0x........: socket (in /...libc...)
    by 0x........: open_socket (socket_close.c:17)
-   by 0x........: main (socket_close.c:31)
+   by 0x........: (below main)

-------------------------------------------------------------------

                       Carl 
Wielaard wrote:
> An RC1 tarball for 3.23.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC1.tar.bz2
> (md5sum = 6d36fd8981d6aab7350f12cc61973be5)
> (sha1sum = 6ff57d5981d774e446853e8b166be8a3bb324601)
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC1.tar.bz2.asc
> 
> 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
> 
> RC2 will appear next week, Wednesday 24 April. And if nothing critical
> emerges after that, a final release will happen on Friday 26 April.
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

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

Test results look fairly good on the platforms I tested.

I did fix a couple of small (testcase) issues for x86:

  32 bit new_delete_mismatch_size and sized_aligned_new_delete_misaligned .exp

and s390x:

  filter out in /absolute/path in drd/tests stderr filter

With those:

RHEL 8.9/x86-64:

== 896 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==

Fedora 39/s390x

== 857 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
drd/tests/bar_bad_xml                    (stderr)
drd/tests/getaddrinfo                    (stderr)

Those two tests are flaky and not always failing.

Fedora ELN x86_64 (this distro is build with -march=x86_64-v3)

== 808 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==

Debian 12.5/arm64

== 727 tests, 8 stderr failures, 0 stdout failures, 0 stderrB failures, 1 stdoutB failure, 0 post failures ==
gdbserver_tests/hgtls                    (stdoutB)
memcheck/tests/dw4                       (stderr)
memcheck/tests/varinfo2                  (stderr)
memcheck/tests/varinfo4                  (stderr)
memcheck/tests/varinfo5                  (stderr)
memcheck/tests/varinfo6                  (stderr)
memcheck/tests/varinforestrict           (stderr)
helgrind/tests/hg05_race2                (stderr)
helgrind/tests/tc20_verifywrap           (stderr)

Almost all are backtrace issues or stack/thread frame issues like

- Location 0x........ is 0 bytes inside local var "rwl2"
- declared at tc20_verifywrap.c:58, in frame #x of thread x
+ Address 0x........ is on thread #x's stack
+ in frame #x, created by main (tc20_verifywrap.c:49)

Fedora 38/ppc64le

== 744 tests, 4 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
drd/tests/bar_bad                        (stderr)
drd/tests/bar_bad_xml                    (stderr)
drd/tests/std_thread2                    (stderr)
none/tests/socket_close                  (stderr)

bar_bad tests seems flaky.

drd/tests/std_thread2 might need a suppression

+Conflicting load by thread 2 at 0x........ size 8
+   at 0x........: _dl_new_hash (dl-new-hash.h:90)
+   by 0x........: _dl_lookup_symbol_x (dl-lookup.c:757)
+Allocation context: Data section of /usr/lib64/ld64.so.2

socket_close looks like the backtrace is skipping main for some reason

    at 0x........: socket (in /...libc...)
    by 0x........: open_socket (socket_close.c:17)
-   by 0x........: main (socket_close.c:31)
+   by 0x........: (below main)


Fedora 40/i386

== 801 tests, 1 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/x86-linux/scalar          (stderr)

Debian 12.5/i686

== 798 tests, 12 stderr failures, 2 stdout failures, 0 stderrB failures, 0 stdoutB failures, 1 post failure ==
memcheck/tests/close_range               (stderr)
memcheck/tests/linux/rfcomm              (stderr)
memcheck/tests/sendmsg                   (stderr)
memcheck/tests/sized_aligned_new_delete_misaligned3_supp (stderr)
memcheck/tests/x86/insn_basic            (stdout)
memcheck/tests/x86/insn_basic            (stderr)
memcheck/tests/x86-linux/scalar          (stderr)
helgrind/tests/pth_mempcpy_false_races   (stderr)
drd/tests/bar_bad                        (stderr)
massif/tests/mmapunmap                   (post)
none/tests/fdleak_ipv4                   (stderr)
none/tests/file_dclose                   (stderr)
none/tests/socket_close                  (stderr)
none/tests/x86/insn_basic                (stdout)
none/tests/x86/insn_basic                (stderr)

Haven't analyzed fully but there are clearly more failures than on
Fedora i386. Some are just things like an extra frame:

+   at 0x........: _dl_sysinfo_int80 (in /usr/lib/i386-linux-gnu/ld-linux.so.2)

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

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

An RC1 tarball for 3.23.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC1.tar.bz2
(md5sum = 6d36fd8981d6aab7350f12cc61973be5)
(sha1sum = 6ff57d5981d774e446853e8b166be8a3bb324601)
https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC1.tar.bz2.asc

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

RC2 will appear next week, Wednesday 24 April. And if nothing critical
emerges after that, a final release will happen on Friday 26 April.

Re: [Valgrind-users] Always investigate valgrind memcheck errors [rjones@redhat.com: Re: xz backdoor]

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

On 30-03-24 11:43, Mark Wielaard wrote:
> For those of you tracking the xz backdoor:
> https://lwn.net/Articles/967180/
> 
> valgrind plays a little role in the discovery.
> 
> "Then recalled that I had seen an odd valgrind complaint in my
> automated testing of postgres, a few weeks earlier, after some package
> updates were installed."  https://lwn.net/Articles/967194/
> 
> See also the attached email, which talks about this bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=2267598
> 
> So please always take valgrind memcheck errors seriously and
> investigate them!
> 
> P.S. Sourceware isn't impacted by this xz backdoor:
> https://fosstodon.org/@sourceware/112180412918966168
> But we did reset the buildbot containers of the affected distros.

Hi Mark

I think RedHat did a good job in the circumstances. It's not easy to 
keep out bad faith attacks like this.

The call stack does look peculiar, particularly the addresses 0x6 and 
0x77AD31E59B84CFFF. It would be interesting to see if there is anything 
mapped to those addresses. 0x1FFEFFF4AF is somewhere around the client 
stack.

I suppose that a debug build would only give more information on the top 
two levels.

==746855== Invalid write of size 8
==746855==    at 0x52E8645: ??? (in /usr/lib64/liblzma.so.5.6.0)
==746855==    by 0x52CA83B: _get_cpuid (in /usr/lib64/liblzma.so.5.6.0)
==746855==    by 0x6: ???
==746855==    by 0x1FFEFFF4AF: ???
==746855==    by 0x77AD31E59B84CFFF: ???
==746855==    by 0x1FFEFFF4AF: ???
==746855==    by 0x400F253: elf_machine_rela (dl-machine.h:314)
==746855==    by 0x400F253: elf_dynamic_do_Rela (do-rel.h:147)
==746855==    by 0x400F253: _dl_relocate_object (dl-reloc.c:301)

A+
Paul

[Valgrind-users] Always investigate valgrind memcheck errors [rjones@redhat.com: Re: xz backdoor]

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

For those of you tracking the xz backdoor:
https://lwn.net/Articles/967180/

valgrind plays a little role in the discovery.

"Then recalled that I had seen an odd valgrind complaint in my
automated testing of postgres, a few weeks earlier, after some package
updates were installed."  https://lwn.net/Articles/967194/

See also the attached email, which talks about this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2267598

So please always take valgrind memcheck errors seriously and
investigate them!

P.S. Sourceware isn't impacted by this xz backdoor:
https://fosstodon.org/@sourceware/112180412918966168
But we did reset the buildbot containers of the affected distros.

Re: [Valgrind-users] Docker Support

[jinesh g. <301...@gm...>]

Dear Paul,

Thank you so much for your quick response.
Yes definitely there's an overhead.

But I tried installation of Valgrind using the tar.gz approach.

It's working fine now in a Ubuntu based docker machine.

On Tue, Mar 5, 2024, 3:45 PM Paul Floyd via Valgrind-users <
val...@li...> wrote:

>
>
> On 04-03-24 11:42, jinesh gada wrote:
> > Hi Everyone,
> >
> > I am working on integrating a docker based application on a virtual
> > machine with Valgrind.
> >
> > I have bind the Valgrind libraries and required folder structure with
> > the container.
> >
> > But on running my app with Valgrind I'm facing an issue saying SIGILL
> > error in ld-2.3.so <http://ld-2.3.so>
> >
> > Can you suggest how shall I proceed.
>
> My basic advice is to not use Docker. I've never used it, but I have
> tried FreeBSD jails. The experience was unsatisfactory. The main problem
> is that these systems only provide lightweight virtualization. That
> means that Valgrind will detect an incorrect or incomplete environment
> and will likely not work correctly.
>
> Full virtualization (VMware, VirtualBox) will work better. The
> virtualization will still not be the same as running directly on the
> underlying operating system but in my experience it is good enough.
>
> A+
> Paul
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Docker Support

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

On 04-03-24 11:42, jinesh gada wrote:
> Hi Everyone,
> 
> I am working on integrating a docker based application on a virtual 
> machine with Valgrind.
> 
> I have bind the Valgrind libraries and required folder structure with 
> the container.
> 
> But on running my app with Valgrind I'm facing an issue saying SIGILL 
> error in ld-2.3.so <http://ld-2.3.so>
> 
> Can you suggest how shall I proceed.

My basic advice is to not use Docker. I've never used it, but I have 
tried FreeBSD jails. The experience was unsatisfactory. The main problem 
is that these systems only provide lightweight virtualization. That 
means that Valgrind will detect an incorrect or incomplete environment 
and will likely not work correctly.

Full virtualization (VMware, VirtualBox) will work better. The 
virtualization will still not be the same as running directly on the 
underlying operating system but in my experience it is good enough.

A+
Paul