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 <kharda...@gmail.com> 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 <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
