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