valgrind-users — General discussion list for Valgrind users

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

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

On 4/24/25 03:59, Mark Wielaard wrote:
> An RC2 tarball for 3.25.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC2.tar.bz2
> (md5sum = 4e53a0a1a8d1404e77e6c45015eeb472)
> (sha1sum = ba482eeeb89dd271006f59b09f01048be6530a53)
> https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC2.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

All OK on

FreeBSD amd64

FreeBSD arm64

illumos amd64

No time to test anything else.

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

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

An RC2 tarball for 3.25.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC2.tar.bz2
(md5sum = 4e53a0a1a8d1404e77e6c45015eeb472)
(sha1sum = ba482eeeb89dd271006f59b09f01048be6530a53)
https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC2.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

Changes from RC1:

Florian Krohm (2):
  s390x: Fix a comment
  s390x only: Clean up unused Ijk_... values

Mark Wielaard (4):
  auxprogs/Makefile.am (EXTRA_DIST): Add ltpchecks helper files
  Update NEWS for RISCV64/Linux and --modify-fds=[no|high] option
  none/tests/riscv64/testinst.h: Use lla instead of la in JMP_RANGE
  Set version to 3.25.0-RC2

Paul Floyd (8):
  Bug 502871 - Make Helgrind "pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread" optional
  Add 3.25 highlights to NEWS for FreeBSD.
  Doc: add description of cond signal without mutex lock.
  Helgrind regtest: use --check-cond-signal-mutex=yes in tc20_verifywrap
  FreeBSD regtest: add auxv_script to dist_noinst_SCRIPTS
  Illumos suppression and regtest
  Illumos regtest: add an expected for none/tests/fdleak_socketpair_xml.stderr
  Regtest: clean up warning and compilation of bug290061.c

Petr Pavlu (4):
  riscv64: Fix tests compilation with newer GNU as
  riscv64: Merge decoding of csrrw and csrrs
  riscv64: Add support for csrrc
  riscv64: Drop the not-needed type for FpCSEL

zhaomingxin (1):
  riscv64: Add missing floating-point ITE/CSEL support in VEX backend

Unless a showstopper bug pops up 3.25.0 final will be released on
Fri Apr 27.

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

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

If you use some piece of shared memory in a process X and this piece of shared memory is
initialized by another process Y, valgrind/X has no way to know that process Y has
initialized this memory.

The typical solution is to have process X marking the memory as initialized just
after it has attached to it.

Thanks
Philippe

On Wed, 2025-04-23 at 01:24 +0530, kiran hardas wrote:
> Hi Team,
> 
> Thanks John Reiser for your observations. In continuation of further valgrind testing, i
> am seeing below type of errors from my application code many times (around 200-300
> times).
> 
> ==3534== Invalid write of size 4
> ==3534==    at 0xF5FAD71: <application backtrace>
> ==3534==    by 0xF5FAD71:  <application backtrace>
> ==3534==    by 0xF1F073F:  <application backtrace>
> ==3534==  Address 0xf7fb1ce4 is not stack'd, malloc'd or (recently) free'd
> 
> 
> The line nos. pointed by these errors are places in code where i am using structure
> pointer variables to access structure members. This structure data is present in shared
> memory location. On printing the structure member values using pointers in debug logs, i
> dont see any problem with value.
> 
> My suspicion is that since we are skipping address advisory logic in valgrind wrapper
> during shmat attach call (passed with shmaddr as NULL), it is attaching to different
> memory location provided by kernel which the valgrind may be detecting as invalid. There
> are many similar errors coming from different parts of application code but relating to
> the same action of structure member access from shared memory.
> 
> One approach i was thinking is to suppress these invalid read errors using suppression
> option of valgrind because i dont see any related symptom of this error, as in no crash
> observed (seg fault). Will it be a proper approach? Would appreciate any
> sugestions/advice for this issue. Or should i need to check any particular code area or
> approach? Please do advice as it would be helpful. Thanks in advance!
> 
> 
> Thanks & Regards,
> Kiran H. 
> 
> On Tue, Apr 15, 2025 at 1:35 AM John Reiser <jr...@bi...> wrote:
> > On 4/14/25 7:13 AM, kiran hardas wrote:
> > > Hi Team,
> > > 
> > > I haven't received any suggestion or advice to my shmat valgrind wrapper 
> > > behaviour mentioned in previous mail.
> > 
> > > --- a/valgrind/coregrind/m_syswrap/syswrap-generic.c
> > > +++ b/valgrind/coregrind/m_syswrap/syswrap-generic.c
> > > @@ -2052,7 +2052,7 @@ ML_(generic_PRE_sys_shmat) ( ThreadId tid,
> > >    {
> > >       /* void *shmat(int shmid, const void *shmaddr, int shmflg); */
> > >       SizeT  segmentSize = get_shm_size ( arg0 );
> > > -   UWord tmp;
> > > +   UWord tmp = 0;
> > >       Bool  ok;
> > >       if (arg1 == 0) {
> > >          /* arm-linux only: work around the fact that
> > 
> > In the current git source for 
> > valgrind/coregrind/m_syswrap/syswrap-generic.c at function 
> > ML_(generic_PRE_sys_shmat) (line 2346), I see
> > =====
> >     if (arg1 == 0) {
> >        /* arm-linux only: work around the fact that
> >           VG_(am_get_advisory_client_simple) produces something that is
> >           VKI_PAGE_SIZE aligned, whereas what we want is something
> >           VKI_SHMLBA aligned, and VKI_SHMLBA >= VKI_PAGE_SIZE.  Hence
> >           increase the request size by VKI_SHMLBA - VKI_PAGE_SIZE and
> >           then round the result up to the next VKI_SHMLBA boundary.
> >           See bug 222545 comment 15.  So far, arm-linux is the only
> >           platform where this is known to be necessary. */
> > =====
> > where "git blame" for the first two lines says
> > =====
> > cc8ccbbfb4 coregrind/m_syswrap/syswrap-generic.c   (Julian Seward 
> > 2005-09-27 19:20:21 +0000 2346)    if (arg1 == 0) {
> > 566a25cf7e coregrind/m_syswrap/syswrap-generic.c   (Julian Seward 
> > 2010-10-06 15:24:39 +0000 2347)       /* arm-linux only: work around the 
> > fact that
> > =====
> > but I do not see any guard that tests for arm-linux only.  So I would
> > say that the current source has a bug!
> > 
> > Thus your change
> > > With this change, my shmat functions calls are working fine as different adresses
> > > are picked up for attach.
> > 
> > is not only OK; it should be propagated into the official source.
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[kiran h. <kha...@gm...>]

Hi Team,

Thanks John Reiser for your observations. In continuation of further
valgrind testing, i am seeing below type of errors from my application code
many times (around 200-300 times).

==3534== Invalid write of size 4
==3534==    at 0xF5FAD71: <application backtrace>
==3534==    by 0xF5FAD71:  <application backtrace>
==3534==    by 0xF1F073F:  <application backtrace>
==3534==  Address 0xf7fb1ce4 is not stack'd, malloc'd or (recently) free'd


The line nos. pointed by these errors are places in code where i am using
structure pointer variables to access structure members. This structure
data is present in shared memory location. On printing the structure member
values using pointers in debug logs, i dont see any problem with value.

My suspicion is that since we are skipping address advisory logic in
valgrind wrapper during shmat attach call (passed with shmaddr as NULL), it
is attaching to different memory location provided by kernel which the
valgrind may be detecting as invalid. There are many similar errors coming
from different parts of application code but relating to the same action of
structure member access from shared memory.

One approach i was thinking is to suppress these invalid read errors using
suppression option of valgrind because i dont see any related symptom of
this error, as in no crash observed (seg fault). Will it be a proper
approach? Would appreciate any sugestions/advice for this issue. Or should
i need to check any particular code area or approach? Please do advice as
it would be helpful. Thanks in advance!


Thanks & Regards,
Kiran H.

On Tue, Apr 15, 2025 at 1:35 AM John Reiser <jr...@bi...> wrote:

> On 4/14/25 7:13 AM, kiran hardas wrote:
> > Hi Team,
> >
> > I haven't received any suggestion or advice to my shmat valgrind wrapper
> > behaviour mentioned in previous mail.
>
> > --- a/valgrind/coregrind/m_syswrap/syswrap-generic.c
> > +++ b/valgrind/coregrind/m_syswrap/syswrap-generic.c
> > @@ -2052,7 +2052,7 @@ ML_(generic_PRE_sys_shmat) ( ThreadId tid,
> >   {
> >      /* void *shmat(int shmid, const void *shmaddr, int shmflg); */
> >      SizeT  segmentSize = get_shm_size ( arg0 );
> > -   UWord tmp;
> > +   UWord tmp = 0;
> >      Bool  ok;
> >      if (arg1 == 0) {
> >         /* arm-linux only: work around the fact that
>
> In the current git source for
> valgrind/coregrind/m_syswrap/syswrap-generic.c at function
> ML_(generic_PRE_sys_shmat) (line 2346), I see
> =====
>     if (arg1 == 0) {
>        /* arm-linux only: work around the fact that
>           VG_(am_get_advisory_client_simple) produces something that is
>           VKI_PAGE_SIZE aligned, whereas what we want is something
>           VKI_SHMLBA aligned, and VKI_SHMLBA >= VKI_PAGE_SIZE.  Hence
>           increase the request size by VKI_SHMLBA - VKI_PAGE_SIZE and
>           then round the result up to the next VKI_SHMLBA boundary.
>           See bug 222545 comment 15.  So far, arm-linux is the only
>           platform where this is known to be necessary. */
> =====
> where "git blame" for the first two lines says
> =====
> cc8ccbbfb4 coregrind/m_syswrap/syswrap-generic.c   (Julian Seward
> 2005-09-27 19:20:21 +0000 2346)    if (arg1 == 0) {
> 566a25cf7e coregrind/m_syswrap/syswrap-generic.c   (Julian Seward
> 2010-10-06 15:24:39 +0000 2347)       /* arm-linux only: work around the
> fact that
> =====
> but I do not see any guard that tests for arm-linux only.  So I would
> say that the current source has a bug!
>
> Thus your change
> > With this change, my shmat functions calls are working fine as different
> adresses are picked up for attach.
>
> is not only OK; it should be propagated into the official source.
>
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

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

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

Hi,

On Tue, 2025-04-22 at 18:37 +0200, Mark Wielaard wrote:
> On Tue, 2025-04-22 at 00:29 +0200, Florian Krohm wrote:
> > On 18.04.25 15:53, Mark Wielaard wrote:
> > > Slightly later than originally planned, but the RC1 is finally out!
> > > 
> > > An RC1 tarball for 3.25.0 is now available at
> > > https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC1.tar.bz2
> > > (md5sum = 2f02fe951278ebde62bba65c3a311a40)
> > > (sha1sum = 3679ddc3237455f07de0ae30f21e947868c2218e)
> > > https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC1.tar.bz2.asc
> > > 
> > > Please give it a try in configurations that are important for you and
> > > report any problems you have
> > 
> > none/tests/bug290061.c
> > bug290061.c:1:13: warning: ‘meh’ defined but not used [-Wunused-variable]
> > 
> > I guess we want a clean build.. Making 'meh' volatile removes the warning.

Sorry, missed that Paul fixed the issue already. That is why I couldn't
replicate :)

Cheers,

Mark

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

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

Hi Florian,

On Tue, 2025-04-22 at 00:29 +0200, Florian Krohm wrote:
> On 18.04.25 15:53, Mark Wielaard wrote:
> > Slightly later than originally planned, but the RC1 is finally out!
> > 
> > An RC1 tarball for 3.25.0 is now available at
> > https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC1.tar.bz2
> > (md5sum = 2f02fe951278ebde62bba65c3a311a40)
> > (sha1sum = 3679ddc3237455f07de0ae30f21e947868c2218e)
> > https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC1.tar.bz2.asc
> > 
> > Please give it a try in configurations that are important for you and
> > report any problems you have
> 
> none/tests/bug290061.c
> bug290061.c:1:13: warning: ‘meh’ defined but not used [-Wunused-variable]
> 
> I guess we want a clean build.. Making 'meh' volatile removes the warning.

I am not seeing that locally. meh is used, although maybe the compiler
is smart enough to notice only meh[0] is actually used. What compiler
(version) and flags are you using?

> These files are missing:
> - auxprogs/ltp-tester.sh
> - auxprogs/ltp-excludes.txt
> - auxprogs/ltp-error-patterns.txt

Oops. Added them to EXTRA_DIST so they are in the tar ball for RC2.

> After adding them make ltpchecks took some 45 minutes on my z15 with about 46 
> failing tests. Not too bad..

I assume most of the failures are missing syscall wrappers? On my
x86_64 setup I got 66 FAILs, full log here:
https://bugsfiles.kde.org/attachment.cgi?id=180366

Cheers,

Mark

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

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

On 4/20/25 04:13, Sean McBride wrote:
> On 19 Apr 2025, at 12:48, Paul Floyd via Valgrind-users wrote:
>
>> I'll give macOS a go shortly.
> macOS?  It hasn't been supported in years, unless I missed some exciting news?

macOS is lagging far behind. In the last 6 months I made 4 changes for 
Darwin

- added the mkdirat syscall wrapper

- fixes for macho reading (to be compatible with ELF)

- one regression test fix

That's only for macOS 10.13 which is very old and probably little used. 
The most recent macOS has moved to arm64.

Louis Brunner has done a lot of work on his GitHub fork 
https://github.com/LouisBrunner/valgrind-macos

Maybe after I've finished getting Illumos back up to speed I'll have a 
go at merging more of that code.


A+

Paul

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

[Sean M. <se...@ro...>]

On 19 Apr 2025, at 12:48, Paul Floyd via Valgrind-users wrote:

> I'll give macOS a go shortly.

macOS?  It hasn't been supported in years, unless I missed some exciting news?

Sean

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

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

On 19-04-25 16:48, Paul Floyd via Valgrind-users wrote:
> 
> On 4/18/25 15:53, Mark Wielaard wrote:
>> Slightly later than originally planned, but the RC1 is finally out!
> 
> Hi Mark
> 
> There was one small regtest issue on FreeBSD (a script missing from 
> dist_noinst_SCRIPTS in none/tests/freebsd/Makefile.am). It's not a 
> blocking issue and it should now be fixed.
> 
> Illumos is also OK.
> 
> I'll give macOS a go shortly.

It builds and sometimes works:

== 705 tests, 194 stderr failures, 11 stdout failures, 0 stderrB 
failures, 0 stdoutB failures, 4 post failures ==

A+
Paul

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

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

On 4/18/25 15:53, Mark Wielaard wrote:
> Slightly later than originally planned, but the RC1 is finally out!

Hi Mark

There was one small regtest issue on FreeBSD (a script missing from 
dist_noinst_SCRIPTS in none/tests/freebsd/Makefile.am). It's not a 
blocking issue and it should now be fixed.

Illumos is also OK.

I'll give macOS a go shortly.

A+

Paul

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

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

Slightly later than originally planned, but the RC1 is finally out!

An RC1 tarball for 3.25.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.25.0.RC1.tar.bz2
(md5sum = 2f02fe951278ebde62bba65c3a311a40)
(sha1sum = 3679ddc3237455f07de0ae30f21e947868c2218e)
https://sourceware.org/pub/valgrind/valgrind-3.25.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

The NEWS file isn't complete up to date yet, but some highlights:

- Initial RISCV64/Linux support.
- Valgrind gdbserver supports 'x' packets.
- Numerous bug fixes for Illumos.
- --track-fds=yes now treats all inherited file descriptors like
  stdin/out/err (0,1,2) and there is a --modify-fds=high option.
- s390x support for various new instructions (BPP, BPRP and NIAI)
- Various new linux syscalls are supported (landlock*, open_tree,
  move_mount, fsopen, fsconfig, fsmount, fspick, userfaultfd)
- The Linux Test Project (ltp) is integrated in the testsuite
  try 'make ltpchecks' (this will take a while and will point out
  various missing syscalls and valgrind crashes!)

Since this RC1 is slightly later than planned and it is a long Easter
weekend for those that celebrate, lets do the RC2 on Wed Apr 25, with
the 3.25.0 final on Fri Apr 27.

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

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

On 4/14/25 7:13 AM, kiran hardas wrote:
> Hi Team,
> 
> I haven't received any suggestion or advice to my shmat valgrind wrapper 
> behaviour mentioned in previous mail.

> --- a/valgrind/coregrind/m_syswrap/syswrap-generic.c
> +++ b/valgrind/coregrind/m_syswrap/syswrap-generic.c
> @@ -2052,7 +2052,7 @@ ML_(generic_PRE_sys_shmat) ( ThreadId tid,
>   {
>      /* void *shmat(int shmid, const void *shmaddr, int shmflg); */
>      SizeT  segmentSize = get_shm_size ( arg0 );
> -   UWord tmp;
> +   UWord tmp = 0;
>      Bool  ok;
>      if (arg1 == 0) {
>         /* arm-linux only: work around the fact that

In the current git source for 
valgrind/coregrind/m_syswrap/syswrap-generic.c at function 
ML_(generic_PRE_sys_shmat) (line 2346), I see
=====
    if (arg1 == 0) {
       /* arm-linux only: work around the fact that
          VG_(am_get_advisory_client_simple) produces something that is
          VKI_PAGE_SIZE aligned, whereas what we want is something
          VKI_SHMLBA aligned, and VKI_SHMLBA >= VKI_PAGE_SIZE.  Hence
          increase the request size by VKI_SHMLBA - VKI_PAGE_SIZE and
          then round the result up to the next VKI_SHMLBA boundary.
          See bug 222545 comment 15.  So far, arm-linux is the only
          platform where this is known to be necessary. */
=====
where "git blame" for the first two lines says
=====
cc8ccbbfb4 coregrind/m_syswrap/syswrap-generic.c   (Julian Seward 
2005-09-27 19:20:21 +0000 2346)    if (arg1 == 0) {
566a25cf7e coregrind/m_syswrap/syswrap-generic.c   (Julian Seward 
2010-10-06 15:24:39 +0000 2347)       /* arm-linux only: work around the 
fact that
=====
but I do not see any guard that tests for arm-linux only.  So I would
say that the current source has a bug!

Thus your change
> With this change, my shmat functions calls are working fine as different adresses are picked up for attach.

is not only OK; it should be propagated into the official source.

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[kiran h. <kha...@gm...>]

Hi Team,

I haven't received any suggestion or advice to my shmat valgrind wrapper
behaviour mentioned in previous mail.
To proceed ahead I have commented the call to
VG_(am_get_advisory_client_simple) function if shmaddr argument value is
passed as 0.
With this the shmaddr value if 0, will be passed to actual shmat syscall as
it is and the kernel then provides an address for attach.
Have pasted the diff below for reference.


--- a/valgrind/coregrind/m_syswrap/syswrap-generic.c
+++ b/valgrind/coregrind/m_syswrap/syswrap-generic.c
@@ -2052,7 +2052,7 @@ ML_(generic_PRE_sys_shmat) ( ThreadId tid,
 {
    /* void *shmat(int shmid, const void *shmaddr, int shmflg); */
    SizeT  segmentSize = get_shm_size ( arg0 );
-   UWord tmp;
+   UWord tmp = 0;
    Bool  ok;
    if (arg1 == 0) {
       /* arm-linux only: work around the fact that
@@ -2067,7 +2067,8 @@ ML_(generic_PRE_sys_shmat) ( ThreadId tid,
       if (VKI_SHMLBA > VKI_PAGE_SIZE) {
          segmentSize += VKI_SHMLBA - VKI_PAGE_SIZE;
       }
-      tmp = VG_(am_get_advisory_client_simple)(0, segmentSize, &ok);
+      //tmp = VG_(am_get_advisory_client_simple)(0, segmentSize, &ok);
+      ok=0; /* skipping the addr advising logic above */
       if (ok) {
          if (VKI_SHMLBA > VKI_PAGE_SIZE) {
             arg1 = VG_ROUNDUP(tmp, VKI_SHMLBA);
diff --git a/valgrind/coregrind/m_syswrap/syswrap-linux.c
b/valgrind/coregrind/m_syswrap/syswrap-linux.c
index 8b23c3e..8184605 100644
--- a/valgrind/coregrind/m_syswrap/syswrap-linux.c
+++ b/valgrind/coregrind/m_syswrap/syswrap-linux.c
@@ -5099,7 +5099,7 @@ PRE(sys_shmat)
       ARG2 = VG_ROUNDDN(ARG2, VKI_SHMLBA);
 #endif
    arg2tmp = ML_(generic_PRE_sys_shmat)(tid, ARG1,ARG2,ARG3);
-   if (arg2tmp == 0)
+   if (arg2tmp == 0  && ARG2 != 0)  /* skipping error condition if shmaddr
is passed as 0 */
       SET_STATUS_Failure( VKI_EINVAL );
    else
       ARG2 = arg2tmp;  // used in POST

Would request your advice if this change is fine and would not affect the
valgrind working.
With this change, my shmat functions calls are working fine as
different adresses are picked up for attach.
But I am not able to verify if there will be any ill-effects of this change
on the entire application working under valgrind.
Would appreciate any kind of insights or suggestions. Thanks in advance.


Thanks & Regards,
Kiran H.


On Sun, Apr 6, 2025 at 12:34 AM kiran hardas <kha...@gm...> wrote:

> Hi Team,
>
> Thanks John for your inputs. I have got a few more observations on shmat
> failure (invalid argument error) under valgrind after debugging by adding
> logs.
>
> As i mentioned earlier, my application code is calling shmat as below
> (verifed the arguments)
>
> data = shmat(shmid, NULL, 0);            /* where data is a struct pointer
> and shmaddr is passed as NULL */
>
> I can see the shmat call is intercepted by valgrind syscall wrapper for
> shmat. This happened after i added all 4 shm functions (shmget, shmat,
> shmdt, shmctl) entries in coregrind/m_syswrap/syswrap-x86-linux.c which
> were missing earlier. There are following wrapper functions for shmat
> function call
>
> PRE(sys_shmget)
>     ML_(generic_PRE_sys_shmat)
>         tmp = VG_(am_get_advisory_client_simple)(0, segmentSize, &ok);
>  // this is advising address and overriding my NULL
>
> POST(sys_shmat)
>     ML_(generic_POST_sys_shmat)
>
> Even though i am passing NULL as shmaddr while calling shmat function from
> application code, in function VG_(am_get_advisory_client_simple) i can see
> an address (in my case 0x1fc15000) is advised to be used for shmat
> overriding the NULL passed by my application. This works successfully for
> the first shmat attach, but later attaches for shmat are failing. This same
> address is advised by this function for successive shmat calls resulting in
> failure with invalid argument as that address is already used for first
> attach shmat call. This is happening even though i am attaching different
> to shm segment id but with same process.
>
> I am not clear why is it advising same address for attach and need some
> help in understanding and resolving this issue.
>
> I am pasting strace output for reference showing shmget and shmat
> functions calls. Here we can see shmget calls are successful but shmat is
> going with same address for all its calls. ( in below strace output, shmctl
> arguments may not be proper in strace, can be ignored)
>
> $/var/run/strace -p 5743 -e
> trace=mmap,munmap,brk,shmctl,shmget,shmat,shmdt,mprotect
> ...
> shmget(0x987c4f, 131072, 0666)          = 0
> shmctl(0, IPC_STAT, {shm_perm={uid=0, gid=0, mode=0140470, key=9993295,
> cuid=438, cgid=131072}, shm_segsz=76, shm_cpid=2285489664,
> shm_lpid=1477341557, shm_nattch=1477341539, shm_atime=0,
> shm_dtime=2285489616, shm_ctime=1}) = 0
> shmat(0, 0x1fc15000, 0)                 = 0x1fc15000
> shmget(0x12940, 2190532, 0666)          = 1
> shmctl(1, IPC_STAT, {shm_perm={uid=0, gid=0, mode=0666, key=76096, cuid=0,
> cgid=0}, shm_segsz=2190532, shm_cpid=2504, shm_lpid=5825, shm_nattch=78,
> shm_atime=1743438136, shm_dtime=1743438136, shm_ctime=1743437461}) = 0
> shmctl(1, IPC_STAT, {shm_perm={uid=0, gid=0, mode=0140470, key=76096,
> cuid=438, cgid=2190532}, shm_segsz=78, shm_cpid=2285489664,
> shm_lpid=1477341557, shm_nattch=1477341539, shm_atime=0,
> shm_dtime=2285489616, shm_ctime=1}) = 0
> shmat(1, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
> shmget(0x98d60, 2190532, IPC_CREAT|0644) = 3
> shmctl(3, IPC_STAT, {shm_perm={uid=0, gid=0, mode=000, key=626016,
> cuid=420, cgid=2190532}, shm_segsz=0, shm_cpid=2285489664,
> shm_lpid=1477341557, shm_nattch=1477341539, shm_atime=0,
> shm_dtime=2285489616, shm_ctime=1}) = 0
> shmat(3, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
> +++ exited with 1 +++
>
> my system values:
> PAGE_SIZE = 4096 = 4kB
> SHMLBA  = 4096 = 4kB
>
> $ uname -a
> Linux 5.4.282 #1 SMP PREEMPT Sat Apr 5 13:16:09 GMT 2025 x86_64 GNU/Linux
>
> Although advising address might be the expected behaviour but then why is
> giving same address?, Need help here as to how should i resolve this issue.
> Is there a way i can skip this advising logic and make it work? Or am i
> still missing any changes that needs to be added for shm functions after
> adding their entry in syswrap-x86-linux.c  file. I tried with shmat with
> SHM_REMAP flag to override earlier attach for same address, although it
> worked but that is not proper way. Please do suggest any approach i can
> take to resolve this issue. Any input is appreciated. For my setup version
> details, please refer my earlier mails in mailchain with Valgrind 3.24.
> Thanks in advance!
>
>
> Thanks & Regards,
> Kiran H.
>
> On Sun, Mar 30, 2025 at 2:34 AM John Reiser <jr...@bi...> wrote:
>
>> > $ /var/run/strace -p 5564 -e shmat
>> > /var/run/strace: Process 5564 attached
>> > /var/run/strace: [ Process PID=5564 runs in 32 bit mode. ]
>> > shmat(0, 0x1fc15000, 0)                 = 0x1fc15000
>> > shmat(1, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
>> > shmat(3, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
>>
>> Please check the documentation which can be read in the output from
>> running the shell command "man 2 shmat".  Each of the three arguments
>> to shmat() is an input value that is specified by your program.
>> So in this case, your program has specified the same value 0x1fc15000
>> to three separate calls of shmat(), which requests that the shared
>> memory segments 0, 1, and 3 be attached sequentially at the same
>> address in the address space of the process, replacing the previous
>> segment.  The documentation does not say anything about such a case.
>> Perhaps shmdt() must be called between successive shmat() which
>> specify the same address?  And are the access permissions the same?
>>
>> Anyway, the address must be a multiple of SHMLBA, which might well
>> be larger than the PAGE_SIZE.  The value 2*PAGE_SIZE (or 4*PAGE_SIZE)
>> might be a common requirement, or perhaps SHMLBA could be much larger.-
>> Please show the output from running the shell command "uname -a"
>> which might provide some hints.  In particular, MIPS hardware often
>> is troublesome.  In another process you specify the address 0x1be88000
>> which is a multiple of 32KB, which is suspiciously larger than 4KB.
>>
>> Also, the "-e shmat" shows occurrences of only that one system call.
>> It might be better to use "-e trace=memory", or "-e trace=shmat,shmdt,
>> shmctl,shmget" to see more information.
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[kiran h. <kha...@gm...>]

Hi Team,

Thanks John for your inputs. I have got a few more observations on shmat
failure (invalid argument error) under valgrind after debugging by adding
logs.

As i mentioned earlier, my application code is calling shmat as below
(verifed the arguments)

data = shmat(shmid, NULL, 0);            /* where data is a struct pointer
and shmaddr is passed as NULL */

I can see the shmat call is intercepted by valgrind syscall wrapper for
shmat. This happened after i added all 4 shm functions (shmget, shmat,
shmdt, shmctl) entries in coregrind/m_syswrap/syswrap-x86-linux.c which
were missing earlier. There are following wrapper functions for shmat
function call

PRE(sys_shmget)
    ML_(generic_PRE_sys_shmat)
        tmp = VG_(am_get_advisory_client_simple)(0, segmentSize, &ok);
 // this is advising address and overriding my NULL

POST(sys_shmat)
    ML_(generic_POST_sys_shmat)

Even though i am passing NULL as shmaddr while calling shmat function from
application code, in function VG_(am_get_advisory_client_simple) i can see
an address (in my case 0x1fc15000) is advised to be used for shmat
overriding the NULL passed by my application. This works successfully for
the first shmat attach, but later attaches for shmat are failing. This same
address is advised by this function for successive shmat calls resulting in
failure with invalid argument as that address is already used for first
attach shmat call. This is happening even though i am attaching different
to shm segment id but with same process.

I am not clear why is it advising same address for attach and need some
help in understanding and resolving this issue.

I am pasting strace output for reference showing shmget and shmat functions
calls. Here we can see shmget calls are successful but shmat is going with
same address for all its calls. ( in below strace output, shmctl arguments
may not be proper in strace, can be ignored)

$/var/run/strace -p 5743 -e
trace=mmap,munmap,brk,shmctl,shmget,shmat,shmdt,mprotect
...
shmget(0x987c4f, 131072, 0666)          = 0
shmctl(0, IPC_STAT, {shm_perm={uid=0, gid=0, mode=0140470, key=9993295,
cuid=438, cgid=131072}, shm_segsz=76, shm_cpid=2285489664,
shm_lpid=1477341557, shm_nattch=1477341539, shm_atime=0,
shm_dtime=2285489616, shm_ctime=1}) = 0
shmat(0, 0x1fc15000, 0)                 = 0x1fc15000
shmget(0x12940, 2190532, 0666)          = 1
shmctl(1, IPC_STAT, {shm_perm={uid=0, gid=0, mode=0666, key=76096, cuid=0,
cgid=0}, shm_segsz=2190532, shm_cpid=2504, shm_lpid=5825, shm_nattch=78,
shm_atime=1743438136, shm_dtime=1743438136, shm_ctime=1743437461}) = 0
shmctl(1, IPC_STAT, {shm_perm={uid=0, gid=0, mode=0140470, key=76096,
cuid=438, cgid=2190532}, shm_segsz=78, shm_cpid=2285489664,
shm_lpid=1477341557, shm_nattch=1477341539, shm_atime=0,
shm_dtime=2285489616, shm_ctime=1}) = 0
shmat(1, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
shmget(0x98d60, 2190532, IPC_CREAT|0644) = 3
shmctl(3, IPC_STAT, {shm_perm={uid=0, gid=0, mode=000, key=626016,
cuid=420, cgid=2190532}, shm_segsz=0, shm_cpid=2285489664,
shm_lpid=1477341557, shm_nattch=1477341539, shm_atime=0,
shm_dtime=2285489616, shm_ctime=1}) = 0
shmat(3, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
+++ exited with 1 +++

my system values:
PAGE_SIZE = 4096 = 4kB
SHMLBA  = 4096 = 4kB

$ uname -a
Linux 5.4.282 #1 SMP PREEMPT Sat Apr 5 13:16:09 GMT 2025 x86_64 GNU/Linux

Although advising address might be the expected behaviour but then why is
giving same address?, Need help here as to how should i resolve this issue.
Is there a way i can skip this advising logic and make it work? Or am i
still missing any changes that needs to be added for shm functions after
adding their entry in syswrap-x86-linux.c  file. I tried with shmat with
SHM_REMAP flag to override earlier attach for same address, although it
worked but that is not proper way. Please do suggest any approach i can
take to resolve this issue. Any input is appreciated. For my setup version
details, please refer my earlier mails in mailchain with Valgrind 3.24.
Thanks in advance!


Thanks & Regards,
Kiran H.

On Sun, Mar 30, 2025 at 2:34 AM John Reiser <jr...@bi...> wrote:

> > $ /var/run/strace -p 5564 -e shmat
> > /var/run/strace: Process 5564 attached
> > /var/run/strace: [ Process PID=5564 runs in 32 bit mode. ]
> > shmat(0, 0x1fc15000, 0)                 = 0x1fc15000
> > shmat(1, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
> > shmat(3, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
>
> Please check the documentation which can be read in the output from
> running the shell command "man 2 shmat".  Each of the three arguments
> to shmat() is an input value that is specified by your program.
> So in this case, your program has specified the same value 0x1fc15000
> to three separate calls of shmat(), which requests that the shared
> memory segments 0, 1, and 3 be attached sequentially at the same
> address in the address space of the process, replacing the previous
> segment.  The documentation does not say anything about such a case.
> Perhaps shmdt() must be called between successive shmat() which
> specify the same address?  And are the access permissions the same?
>
> Anyway, the address must be a multiple of SHMLBA, which might well
> be larger than the PAGE_SIZE.  The value 2*PAGE_SIZE (or 4*PAGE_SIZE)
> might be a common requirement, or perhaps SHMLBA could be much larger.-
> Please show the output from running the shell command "uname -a"
> which might provide some hints.  In particular, MIPS hardware often
> is troublesome.  In another process you specify the address 0x1be88000
> which is a multiple of 32KB, which is suspiciously larger than 4KB.
>
> Also, the "-e shmat" shows occurrences of only that one system call.
> It might be better to use "-e trace=memory", or "-e trace=shmat,shmdt,
> shmctl,shmget" to see more information.
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

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

> $ /var/run/strace -p 5564 -e shmat
> /var/run/strace: Process 5564 attached
> /var/run/strace: [ Process PID=5564 runs in 32 bit mode. ]
> shmat(0, 0x1fc15000, 0)                 = 0x1fc15000
> shmat(1, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
> shmat(3, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)

Please check the documentation which can be read in the output from
running the shell command "man 2 shmat".  Each of the three arguments
to shmat() is an input value that is specified by your program.
So in this case, your program has specified the same value 0x1fc15000
to three separate calls of shmat(), which requests that the shared
memory segments 0, 1, and 3 be attached sequentially at the same
address in the address space of the process, replacing the previous
segment.  The documentation does not say anything about such a case.
Perhaps shmdt() must be called between successive shmat() which
specify the same address?  And are the access permissions the same?

Anyway, the address must be a multiple of SHMLBA, which might well
be larger than the PAGE_SIZE.  The value 2*PAGE_SIZE (or 4*PAGE_SIZE)
might be a common requirement, or perhaps SHMLBA could be much larger.-
Please show the output from running the shell command "uname -a"
which might provide some hints.  In particular, MIPS hardware often
is troublesome.  In another process you specify the address 0x1be88000
which is a multiple of 32KB, which is suspiciously larger than 4KB.

Also, the "-e shmat" shows occurrences of only that one system call.
It might be better to use "-e trace=memory", or "-e trace=shmat,shmdt,
shmctl,shmget" to see more information.

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[kiran h. <kha...@gm...>]

Hi Team,

Regarding the shmat "invalid argument" error, in continuation of debugging
the issue, I have got further info.
I used strace on my valgrind process id to understand better. It gave the
following output for shmat function calls of my application,

$ /var/run/strace -p 5564 -e shmat
/var/run/strace: Process 5564 attached
/var/run/strace: [ Process PID=5564 runs in 32 bit mode. ]
shmat(0, 0x1fc15000, 0)                 = 0x1fc15000
shmat(1, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
shmat(3, 0x1fc15000, 0)                 = -1 EINVAL (Invalid argument)
+++ exited with 1 +++

shmat function is called like this in my application code,
data = shmat(shmid, NULL, 0);            /* where data is a struct pointer
*/

Here we can see that for 1st shmat call, we get an address 0x1fc15000 by
default to attach.
But for 2nd and 3rd shmat call by the same application process we can see
the same address is getting used
for attach purpose due to which it is failing and giving invalid argument
error.

Setup details are as follows,
GNU/Linux 5.4
Glibc 2.40
gcc 14.2
binutils 2.43
valgrind-3.24.0

I tried similar check on my old version of application and it showed
different address for shmat purpose as seen below,

$ /var/run/strace -p 4336 -e shmat -v
/var/run/strace: Process 4336 attached
/var/run/strace: [ Process PID=4336 runs in 32 bit mode. ]
shmat(0, 0x1be88000, 0)                 = 0x1be88000
shmat(1, 0x1bea8000, 0)                 = 0x1bea8000

my old setup details are as follows,
GNU/Linux 5.4
Glibc 2.23
gcc 8.5
binutils 2.32
valgrind-3.18.0

In my old application version, this shmat function is working fine with
valgrind. But with new glibc and new Valgrind, shmat is giving
invalid argument error. Also if i use old valgrind 3.18 with my latest
application version, it still gives same shmat error.

Is this abnormal behaviour from valgrind or from glibc? any inputs here?
(Note: only shmat is showing error, shmget is working proper under valgrind)


Thanks & Regards,
Kiran H.








On Mon, Mar 24, 2025 at 9:03 PM kiran hardas <kha...@gm...> wrote:

> Hi Paul,
>
> Thanks for taking time and providing inputs. I am still debugging for that
> shmat failure, so far no rca.
> The error string that i got from perror after shmat is "Invalid argument".
>
>
> Regards,
> Kiran H.
>
> On Sat, Mar 22, 2025 at 2:18 AM Paul Floyd <pj...@wa...> wrote:
>
>>
>> On 21/03/2025 09:06, kiran hardas wrote:
>> > Hi Paul/Team,
>> >
>> > Thank you for your suggestion. I added the entry for shmget function
>> > in coregrind/m_syswrap/syswrap-x86-linux.c
>> > and the error got resolved for shmget function. Yes it is x86 linux
>> > that is getting used. Similar errors came for shmat, shmdt, shmctl
>> > functions.
>> > I added similar entries of those functions too in the table and
>> > resolved the errors.
>> >
>> > Currently i am getting error from shmat function as "Invalid argument"
>> > from my application code.
>> > The data pointer returned by shmat function is coming as 0xffffffff
>> > which is -1 (error). I am calling the shmat as below
>> >  in my application code
>> >
>> > data = shmat(shmid, NULL, 0);            /* where data is a struct
>> > pointer and shmid is 1 obtained by a successful shmget call */
>> >
>> > I verified the arguments for this shmat function and they seem to be
>> > fine. Also checked for permission issues.
>> > I am suspecting memory issue which could be resulting in shmat attach
>> > failure after running valgrind (have glibc 2.40).
>> >
>> > Would appreciate any advice/suggestion you can provide for this issue.
>> >
>>
>> Hi
>>
>> On the Valgrind side I've pushed a change that adds these 4 syscalls to
>> x86 Linux.
>>
>> I can't tell why your shmat call is failing. If the shmget call to
>> obtain shmid works than it ought to work. The man page lists the error
>> conditions. What do you get in errno?
>>
>> It might be worth checking with the ipcs command to see if hou have lots
>> of leftover memorys/queues/semaphores.
>>
>>
>> A+
>>
>> Paul
>>
>>

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[kiran h. <kha...@gm...>]

Hi Paul,

Thanks for taking time and providing inputs. I am still debugging for that
shmat failure, so far no rca.
The error string that i got from perror after shmat is "Invalid argument".


Regards,
Kiran H.

On Sat, Mar 22, 2025 at 2:18 AM Paul Floyd <pj...@wa...> wrote:

>
> On 21/03/2025 09:06, kiran hardas wrote:
> > Hi Paul/Team,
> >
> > Thank you for your suggestion. I added the entry for shmget function
> > in coregrind/m_syswrap/syswrap-x86-linux.c
> > and the error got resolved for shmget function. Yes it is x86 linux
> > that is getting used. Similar errors came for shmat, shmdt, shmctl
> > functions.
> > I added similar entries of those functions too in the table and
> > resolved the errors.
> >
> > Currently i am getting error from shmat function as "Invalid argument"
> > from my application code.
> > The data pointer returned by shmat function is coming as 0xffffffff
> > which is -1 (error). I am calling the shmat as below
> >  in my application code
> >
> > data = shmat(shmid, NULL, 0);            /* where data is a struct
> > pointer and shmid is 1 obtained by a successful shmget call */
> >
> > I verified the arguments for this shmat function and they seem to be
> > fine. Also checked for permission issues.
> > I am suspecting memory issue which could be resulting in shmat attach
> > failure after running valgrind (have glibc 2.40).
> >
> > Would appreciate any advice/suggestion you can provide for this issue.
> >
>
> Hi
>
> On the Valgrind side I've pushed a change that adds these 4 syscalls to
> x86 Linux.
>
> I can't tell why your shmat call is failing. If the shmget call to
> obtain shmid works than it ought to work. The man page lists the error
> conditions. What do you get in errno?
>
> It might be worth checking with the ipcs command to see if hou have lots
> of leftover memorys/queues/semaphores.
>
>
> A+
>
> Paul
>
>

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

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

On 21/03/2025 09:06, kiran hardas wrote:
> Hi Paul/Team,
>
> Thank you for your suggestion. I added the entry for shmget function 
> in coregrind/m_syswrap/syswrap-x86-linux.c
> and the error got resolved for shmget function. Yes it is x86 linux 
> that is getting used. Similar errors came for shmat, shmdt, shmctl 
> functions.
> I added similar entries of those functions too in the table and 
> resolved the errors.
>
> Currently i am getting error from shmat function as "Invalid argument" 
> from my application code.
> The data pointer returned by shmat function is coming as 0xffffffff 
> which is -1 (error). I am calling the shmat as below
>  in my application code
>
> data = shmat(shmid, NULL, 0);            /* where data is a struct 
> pointer and shmid is 1 obtained by a successful shmget call */
>
> I verified the arguments for this shmat function and they seem to be 
> fine. Also checked for permission issues.
> I am suspecting memory issue which could be resulting in shmat attach 
> failure after running valgrind (have glibc 2.40).
>
> Would appreciate any advice/suggestion you can provide for this issue.
>

Hi

On the Valgrind side I've pushed a change that adds these 4 syscalls to 
x86 Linux.

I can't tell why your shmat call is failing. If the shmget call to 
obtain shmid works than it ought to work. The man page lists the error 
conditions. What do you get in errno?

It might be worth checking with the ipcs command to see if hou have lots 
of leftover memorys/queues/semaphores.


A+

Paul

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

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

On 3/21/25 09:06, kiran hardas wrote:
> Hi Paul/Team,
>
> Thank you for your suggestion. I added the entry for shmget function 
> in coregrind/m_syswrap/syswrap-x86-linux.c
> and the error got resolved for shmget function. Yes it is x86 linux 
> that is getting used. Similar errors came for shmat, shmdt, shmctl 
> functions.
> I added similar entries of those functions too in the table and 
> resolved the errors.
>
> Currently i am getting error from shmat function as "Invalid argument" 
> from my application code.
> The data pointer returned by shmat function is coming as 0xffffffff 
> which is -1 (error). I am calling the shmat as below
>  in my application code
>
> data = shmat(shmid, NULL, 0);            /* where data is a struct 
> pointer and shmid is 1 obtained by a successful shmget call */
>
> I verified the arguments for this shmat function and they seem to be 
> fine. Also checked for permission issues.
> I am suspecting memory issue which could be resulting in shmat attach 
> failure after running valgrind (have glibc 2.40).
>
> Would appreciate any advice/suggestion you can provide for this issue.
>
Hi

I'll have a look this weekend.

A+

Paul

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[kiran h. <kha...@gm...>]

Hi Paul/Team,

Thank you for your suggestion. I added the entry for shmget function in
coregrind/m_syswrap/syswrap-x86-linux.c
and the error got resolved for shmget function. Yes it is x86 linux that
is getting used. Similar errors came for shmat, shmdt, shmctl functions.
I added similar entries of those functions too in the table and resolved
the errors.

Currently i am getting error from shmat function as "Invalid argument" from
my application code.
The data pointer returned by shmat function is coming as 0xffffffff which
is -1 (error). I am calling the shmat as below
 in my application code

data = shmat(shmid, NULL, 0);            /* where data is a struct pointer
and shmid is 1 obtained by a successful shmget call */

I verified the arguments for this shmat function and they seem to be fine.
Also checked for permission issues.
I am suspecting memory issue which could be resulting in shmat attach
failure after running valgrind (have glibc 2.40).

Would appreciate any advice/suggestion you can provide for this issue.

Thanks in advance

On Sun, Mar 16, 2025 at 1:47 AM Paul Floyd via Valgrind-users <
val...@li...> wrote:

>
> On 3/12/25 22:40, kiran hardas wrote:
> > Hi Philippe/Team,
> >
> > Thank you Philippe for your suggestions, I was able to resolve the
> > earlier errors by adding additional valgrind options and loading the
> > symbol table.
> > In my application, few variables and a function pointer was
> > uninitialised which led to previous errors mentioned in earlier email.
> >
> > Proceeding further with my earlier activity, right now i am
> > seeing error related to unhandled syscall no. 395 in valgrind logs. I
> > thought to bring this up in this mail chain for your suggestions/inputs.
> >
> >
> > # ./usr/test/bin/valgrind --version -v
> > valgrind-3.24.0-fcdaa47426-20241101
> >
> > GNU/Linux 5.4
> > Glibc 2.40
> > gcc 14.2
> > binutils 2.43
> >
> >
> > Error snippet:
> >
> > --6423-- WARNING: unhandled x86-linux syscall: 395
> > ==6423==    at 0x1F757398: shmget (in /lib/libc-2.40.so
> > <http://libc-2.40.so>)
> > by 0xF597083: <application backtraces>
> > ...
> > ...
> > --6423-- You may be able to write your own handler.
> > --6423-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> > --6423-- Nevertheless we consider this a bug.  Please report
> > --6423-- it at http://valgrind.org/support/bug_reports.html.
> >
> > From my analysis of valgrind code, i can see the shmget wrappers are
> > present in coregrind/m_syswrap area, but still it is throwing such error.
> >
> > Any pointers or suggestions would be appreciated, Thanks.
> >
> Hi
>
> That looks like shmget on x86. Can you confirm that?
>
> If so could you build valgrind with this patch
>
> diff --git a/coregrind/m_syswrap/syswrap-x86-linux.c
> b/coregrind/m_syswrap/syswrap-x86-l
> inux.c
> index 50384817d..5c0b57789 100644
> --- a/coregrind/m_syswrap/syswrap-x86-linux.c
> +++ b/coregrind/m_syswrap/syswrap-x86-linux.c
> @@ -1621,6 +1621,8 @@static SyscallTableEntry syscall_table[] = {
>
>     GENX_(__NR_rseq,              sys_ni_syscall),       // 386
>
> +   LINX_(__NR_shmget,            sys_shmget),           // 395
> +
>     LINXY(__NR_clock_gettime64,   sys_clock_gettime64),  // 403
>     LINX_(__NR_clock_settime64,   sys_clock_settime64),  // 404
>
>
> and let us know if it works?
>
> It's likely that you will also need shmat shmctl and shmdt as well.
>
> A+
>
> Paul
>
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

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

On 3/12/25 22:40, kiran hardas wrote:
> Hi Philippe/Team,
>
> Thank you Philippe for your suggestions, I was able to resolve the 
> earlier errors by adding additional valgrind options and loading the 
> symbol table.
> In my application, few variables and a function pointer was 
> uninitialised which led to previous errors mentioned in earlier email.
>
> Proceeding further with my earlier activity, right now i am 
> seeing error related to unhandled syscall no. 395 in valgrind logs. I 
> thought to bring this up in this mail chain for your suggestions/inputs.
>
>
> # ./usr/test/bin/valgrind --version -v
> valgrind-3.24.0-fcdaa47426-20241101
>
> GNU/Linux 5.4
> Glibc 2.40
> gcc 14.2
> binutils 2.43
>
>
> Error snippet:
>
> --6423-- WARNING: unhandled x86-linux syscall: 395
> ==6423==    at 0x1F757398: shmget (in /lib/libc-2.40.so 
> <http://libc-2.40.so>)
> by 0xF597083: <application backtraces>
> ...
> ...
> --6423-- You may be able to write your own handler.
> --6423-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> --6423-- Nevertheless we consider this a bug.  Please report
> --6423-- it at http://valgrind.org/support/bug_reports.html.
>
> From my analysis of valgrind code, i can see the shmget wrappers are 
> present in coregrind/m_syswrap area, but still it is throwing such error.
>
> Any pointers or suggestions would be appreciated, Thanks.
>
Hi

That looks like shmget on x86. Can you confirm that?

If so could you build valgrind with this patch

diff --git a/coregrind/m_syswrap/syswrap-x86-linux.c 
b/coregrind/m_syswrap/syswrap-x86-l
inux.c
index 50384817d..5c0b57789 100644
--- a/coregrind/m_syswrap/syswrap-x86-linux.c
+++ b/coregrind/m_syswrap/syswrap-x86-linux.c
@@ -1621,6 +1621,8 @@static SyscallTableEntry syscall_table[] = {

    GENX_(__NR_rseq,              sys_ni_syscall),       // 386

+   LINX_(__NR_shmget,            sys_shmget),           // 395
+
    LINXY(__NR_clock_gettime64,   sys_clock_gettime64),  // 403
    LINX_(__NR_clock_settime64,   sys_clock_settime64),  // 404


and let us know if it works?

It's likely that you will also need shmat shmctl and shmdt as well.

A+

Paul

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[kiran h. <kha...@gm...>]

Hi Philippe/Team,

Thank you Philippe for your suggestions, I was able to resolve the earlier
errors by adding additional valgrind options and loading the symbol table.
In my application, few variables and a function pointer was uninitialised
which led to previous errors mentioned in earlier email.

Proceeding further with my earlier activity, right now i am seeing error
related to unhandled syscall no. 395 in valgrind logs. I thought to bring
this up in this mail chain for your suggestions/inputs.


# ./usr/test/bin/valgrind --version -v
valgrind-3.24.0-fcdaa47426-20241101

GNU/Linux 5.4
Glibc 2.40
gcc 14.2
binutils 2.43


Error snippet:

--6423-- WARNING: unhandled x86-linux syscall: 395
==6423==    at 0x1F757398: shmget (in /lib/libc-2.40.so)
by 0xF597083:  <application backtraces>
...
...
--6423-- You may be able to write your own handler.
--6423-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--6423-- Nevertheless we consider this a bug.  Please report
--6423-- it at http://valgrind.org/support/bug_reports.html.

>From my analysis of valgrind code, i can see the shmget wrappers are
present in coregrind/m_syswrap area, but still it is throwing such error.

Any pointers or suggestions would be appreciated, Thanks.




Regards,
Kiran H.

On Thu, Jan 30, 2025 at 1:54 AM Philippe Waroquiers <
phi...@sk...> wrote:

> Is glibc compiled with debug info ?
> Without a way to see where the problem happens in glibc, this will be
> difficult
> to understand.
> If/when you have glibc debug info, you might use valgrind --vgdb-error=0
> and debug
> glibc startup under valgrind+gdb
>
> Alternatively, you might add -v -v -v -d -d -d to have more information
> produced by
> valgrind, but that will likely not help much without glibc debug.
>
> In the original mail, you show an extract of the error logs.
> Was there any other error before ?
> Because the problem might originate from an earlier error.
>
> Finally, do you encounter the same problem with e.g. --tool=none or
> --tool=callgrind ?
> (none will do no transformation to the guest process and callgrind will
> not replace
> malloc/free, so that might give a hint).
>
> Thanks
> Philippe
>
>
>
>
> On Thu, 2025-01-30 at 01:00 +0530, kiran hardas wrote:
> > Yes Philippe, I did try out Valgrind 3.24, but it too gave same error.
> >
> > Regards,
> > Kiran H.
> >
> > On Wed, Jan 29, 2025 at 11:56 PM Philippe Waroquiers <
> phi...@sk...>
> > wrote:
> > > The first thing to try is to compile and use a more recent valgrind
> version.
> > > (3.18 is something like 4 years old while 3.24 is from Oct 24).
> > >
> > > Thanks
> > > Philippe
> > >
> > >
> > > On Wed, 2025-01-29 at 19:03 +0530, kiran hardas wrote:
> > > > Hi Team,
> > > >
> > > > Good Evening,
> > > >
> > > > I need some support in debugging an issue in Valgrind 3.18.
> > > >
> > > > I have an application which I am trying to check with Valgrind tool
> for memory
> > > > issues. I
> > > > have the valgrind source code which is compiled and built along with
> my application
> > > > using same set of libraries. But while checking with valgrind tool i
> get an invalid
> > > > address error in libc library (mostly implying null pointer
> dereferencing/free) and
> > > > valgrind is terminating. I am unable to find the exact place in
> glibc code where
> > > > this
> > > > error is coming from and need any help which you can provide.
> > > >
> > > > Please find further details below,
> > > >
> > > > $ ./usr/test/bin/valgrind --version -v
> > > > valgrind-3.18.1-42b08ed5bd-20211015
> > > >
> > > > GNU/Linux 5.4
> > > > Glibc 2.40
> > > > gcc 14.2
> > > > binutils 2.43
> > > >
> > > > This same valgrind was working when i was using glibc 2.23 but
> giving this error
> > > > when i
> > > > upgraded glibc to 2.40
> > > > For valgrind 3.18 i have applied rseq patches and nop code error
> (0x2E 0x8D 0xB4
> > > > 0x26)
> > > > patches also required for latest glibc 2.40.
> > > >
> > > > Error log snippet:
> > > > ------------------------
> > > > ...
> > > > ...
> > > > ==13089==
> > > > --13089-- REDIR: 0x1f749f60 (libc.so.6:???) redirected to 0x1e59bd70
> (strcmp)
> > > > ==13089== Jump to the invalid address stated on the next line
> > > > ==13089==    at 0x0: ???
> > > > ==13089==    by 0x1F607366: ??? (in /lib/libc-2.40.so)
> > > > ==13089==    by 0x1F607423: (below main) (in /lib/libc-2.40.so)
> > > > ==13089==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> > > > ==13089==
> > > > ==13089==
> > > > ==13089== Process terminating with default action of signal 11
> (SIGSEGV): dumping
> > > > core
> > > > ==13089==  Bad permissions for mapped region at address 0x0
> > > > ==13089==    at 0x0: ???
> > > > ==13089==    by 0x1F607366: ??? (in /lib/libc-2.40.so)
> > > > ==13089==    by 0x1F607423: (below main) (in /lib/libc-2.40.so)
> > > > ==13089==
> > > >
> > > >
> > > > Approaches tried
> > > > -----------------------
> > > > 1. I reduced the optimisation level in glibc to -O1, but still no
> further symbol
> > > > details
> > > > are available
> > > > 2. The core file generated for valgrind crash is also not showing
> any symbol details
> > > > at
> > > > crash point. (only showing ??)
> > > > 3. Tried adding more option to valgrind like --track-origins=yes
> , --read-var-
> > > > info=yes .
> > > > But not giving any more info for the error.
> > > >
> > > >
> > > > I would appreciate any pointers team can provide in debugging this
> issue.
> > > >
> > > > Thanks in advance
> > > >
> > > > Regards,
> > > > Kiran H.
> > > >
> > > > _______________________________________________
> > > > Valgrind-users mailing list
> > > > Val...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > >
>
>

Re: [Valgrind-users] Valgrind runs way slower on faster PC

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

On 2/10/25 12:44 AM, Lev Yudalevich wrote:
> My first PC has i7-6700K @ 4.00GHz x 8 CPU, 32GiB RAM
> My second PC has i7-10700 @ 2.90GHz x 16 CPU, 64GiB RAM
> Both machines have identical OS installation (Ubuntu 22.04.5 LTS) rest 
> of the software (toolchains etc).
> However, running Valgrind (version 3.25.0.GIT) with the same test 
> program on a second (presumably more powerful) machine is more than 
> twice slower than running the same on the first machine.

Run "sudo dmidecode >dmidecode.out" and compare the cache sizes and
associativity.  Run "grep cache /proc/cpuinfo".  Also run "lscpu".
What is the TLB size?  Boot the standalone memtest86+ and check
the measured speed of caches and RAM.

Re: [Valgrind-users] Valgrind runs way slower on faster PC

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

On 10-02-25 09:44, Lev Yudalevich wrote:
> My first PC has i7-6700K @ 4.00GHz x 8 CPU, 32GiB RAM
> My second PC has i7-10700 @ 2.90GHz x 16 CPU, 64GiB RAM
> Both machines have identical OS installation (Ubuntu 22.04.5 LTS) rest 
> of the software (toolchains etc).
> However, running Valgrind (version 3.25.0.GIT) with the same test 
> program on a second (presumably more powerful) machine is more than 
> twice slower than running the same on the first machine. What can be a 
> reason for this? I'd really appreciate any hint/help/idea. Thank you. Lev.


Any patches to speed up Valgrind would be welcome ;-)


Seriously, one common mistake that I often see new users make is 
overdoing it with the Valgrind options. Just because Valgrind has many 
options doesn't mean that you should use them all. As a rule the more 
options you add the slower Valgrind will run.

I'm going to assume that it's memcheck that you are using.

If you're just running tests
----------------------------
Really minimise your use of options. You may need --trace-children=yes 
(and possibly --trace-children-skip= if your exe forks a lot of other 
processes), Don't check for leaks unless the leak summary says that you 
have leaks. Don't use --track-origins=yes until you have detected a 
"Conditional jump" error.

If you know you have an error and you want to debug it
------------------------------------------------------
This is where you want to start turning on options like
--track-origins=yes and --read-var-info=yes.

A+
Paul

Re: [Valgrind-users] --32556:0:libcfile Valgrind: FATAL: Private file creation failed.

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

> On 11 Feb 2025, at 04:38, Jessica Long <jes...@gm...> wrote:
> 
> Not sure what to do. I'm new to Linux and Valgrind. 
> 
> I'm on CLion, and I'm trying to run my code with Valgrind memcheck.  However I get the message. 
> 
> --33110:0:libcfile Valgrind: FATAL: Private file creation failed.
>    The current file descriptor limit is 1073741804.
>    If you are running in Docker please consider
>    lowering this limit with the shell built-in limit command.
> --33110:0:libcfile Exiting now.
> 


Hi

Are you using Docker?

If you are, here is what is happening. Valgrind tries to make itself invisible to the rest application that it is testing. Since Valgrind uses some files itself (e.g., for the log) it reserves for itself a small number of file descriptors. These files will use the highest possible file descriptors. In order that this seems (mostly) invisible Valgrind will also change the ‘resource limit’ for file descriptors ilimit is the API that developers should use to query things like file descriptor limits. On a real Linux instance the file descriptor limit is something sensible like 65536.

Enter Docker.

Docker screws up the file descriptor limit. For some reason, instead of using the same sensible limit that the host is using Docker sets the limit to the maximum theoretical limit (possibly by querying the kernel sysctl fs.file-max). In your case that is a billion files. So when Valgrind runs it will try to use file descriptors up around the 1 billion mark for its own use. When this happens the Linux kernel tries to extend the array of structures that it uses for files up to the file descriptor that Valgrind has requested. Typically that is an infeasibly large amount of memory, and the allocation request will fail. Valgrind gets back an error code (ENOMEM - not enough memory) and it terminates because it can’t continue without being able to use files.

Solutions

I don’t know if you can tell Docker to use a sensible file descriptor limit.

Otherwise, when you are running a shell inside Docker, before you run CLion, enter the command

ulimit -n 65536

(that is for sh and bash, csh has a similar command).

A+
Paul