valgrind-users — General discussion list for Valgrind users

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

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

[Jessica L. <jes...@gm...>]

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.

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

[Lev Y. <lyu...@gm...>]

Sure. Here we go:

perf stat on first PC (i7-6700K @ 4.00GHz x 8 CPU, 32GiB RAM):

        395,282.24 msec task-clock                       #    5.612 CPUs
utilized
         4,982,318      context-switches                 #   12.604 K/sec

         1,258,234      cpu-migrations                   #    3.183 K/sec

         1,698,192      page-faults                      #    4.296 K/sec

 1,558,005,376,132      cycles                           #    3.942 GHz

 1,085,678,118,192      instructions                     #    0.70  insn
per cycle
   130,242,817,239      branches                         #  329.493 M/sec

     1,513,065,695      branch-misses                    #    1.16% of all
branches

      70.439261508 seconds time elapsed
     351.168298000 seconds user
      44.239862000 seconds sys


perf stat on second PC (i7-10700 @ 2.90GHz x 16 CPU, 64GiB RAM):

        277,595.50 msec task-clock                       #    8.502 CPUs
utilized
         3,356,252      context-switches                 #   12.090 K/sec

           872,020      cpu-migrations                   #    3.141 K/sec

         1,671,597      page-faults                      #    6.022 K/sec

 1,257,017,696,457      cycles                           #    4.528 GHz

   590,118,043,095      instructions                     #    0.47  insn
per cycle
    70,240,995,962      branches                         #  253.034 M/sec

       734,712,605      branch-misses                    #    1.05% of all
branches

      32.651035006 seconds time elapsed
     254.315463000 seconds user
      23.384174000 seconds sys


On Mon, 10 Feb 2025 at 13:26, Simon Sobisch <sim...@gn...> wrote:

> Just out of interest: can you run
>
>      perf stat yourprog
>
> (depending on your setup that may need root or a temporary adjustment of
> the paranoid setting) on both machines and share the results - just to
> know what we're actually talking about...
>
> Simon
>
> Am 10.02.2025 um 11:02 schrieb Lev Yudalevich:
> > The program being tested is not single-threaded. In fact, it is
> > "extremely" multi-threaded. That's why I was expecting faster runs.
> >
> > On Mon, 10 Feb 2025 at 11:54, David Faure <fa...@kd...
> > <mailto:fa...@kd...>> wrote:
> >
> >     On Monday, 10 February 2025 09:44:39 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.
> >
> >     2.9 GHz < 4.0 GHz so it seems to me the second PC has a slower CPU.
> >     Assuming that the program is single-threaded, this explains why the
> >     second
> >     machine is actually slower.
> >
> >     --
> >     David Faure, fa...@kd... <mailto:fa...@kd...>, http://
> >     www.davidfaure.fr <http://www.davidfaure.fr>
> >
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>

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

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

Just out of interest: can you run

     perf stat yourprog

(depending on your setup that may need root or a temporary adjustment of 
the paranoid setting) on both machines and share the results - just to 
know what we're actually talking about...

Simon

Am 10.02.2025 um 11:02 schrieb Lev Yudalevich:
> The program being tested is not single-threaded. In fact, it is 
> "extremely" multi-threaded. That's why I was expecting faster runs.
> 
> On Mon, 10 Feb 2025 at 11:54, David Faure <fa...@kd... 
> <mailto:fa...@kd...>> wrote:
> 
>     On Monday, 10 February 2025 09:44:39 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.
> 
>     2.9 GHz < 4.0 GHz so it seems to me the second PC has a slower CPU.
>     Assuming that the program is single-threaded, this explains why the
>     second
>     machine is actually slower.
> 
>     -- 
>     David Faure, fa...@kd... <mailto:fa...@kd...>, http://
>     www.davidfaure.fr <http://www.davidfaure.fr>
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[Lev Y. <lyu...@gm...>]

Now I got it. Thank you very much!

On Mon, 10 Feb 2025 at 12:17, Tobias Bading <tb...@we...> wrote:

> On 10. Feb 2025, at 11:04, Lev Yudalevich <lyu...@gm...> wrote:
>
> The program being tested is not single-threaded. In fact, it is
> "extremely" multi-threaded. That's why I was expecting faster runs.
>
>
> Your application does not run multi-threaded under Valgrind, see
> https://valgrind.org/docs/manual/manual-core.html#manual-core.pthreads.
>

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

[Tobias B. <tb...@we...>]

> On 10. Feb 2025, at 11:04, Lev Yudalevich <lyu...@gm...> wrote:
> The program being tested is not single-threaded. In fact, it is "extremely" multi-threaded. That's why I was expecting faster runs.

Your application does not run multi-threaded under Valgrind, see https://valgrind.org/docs/manual/manual-core.html#manual-core.pthreads.

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

[Lev Y. <lyu...@gm...>]

The program being tested is not single-threaded. In fact, it is "extremely"
multi-threaded. That's why I was expecting faster runs.

On Mon, 10 Feb 2025 at 11:54, David Faure <fa...@kd...> wrote:

> On Monday, 10 February 2025 09:44:39 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.
>
> 2.9 GHz < 4.0 GHz so it seems to me the second PC has a slower CPU.
> Assuming that the program is single-threaded, this explains why the second
> machine is actually slower.
>
> --
> David Faure, fa...@kd..., http://www.davidfaure.fr
>

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

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

On Monday, 10 February 2025 09:44:39 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.

2.9 GHz < 4.0 GHz so it seems to me the second PC has a slower CPU.
Assuming that the program is single-threaded, this explains why the second 
machine is actually slower.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr

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

[Lev Y. <lyu...@gm...>]

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.