Re: Need support in debugging Valgrind 3.18 glibc segv error
kiran hardas <[email protected]> Mon, 14 Apr 2025 19:43:38 +0530
| Newsgroups | gmane.comp.debugging.valgrind |
|---|---|
| Message-ID | <CAPyEgmb_4ze_QkEoffZyDkP0acBsrbgeAkSZMSy_ddzdgbuaUg@mail.gmail.com> |
--===============7941610911301366627==
Content-Type: multipart/alternative; boundary="0000000000004ebd7d0632bda9b5"
--0000000000004ebd7d0632bda9b5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 =3D get_shm_size ( arg0 );
- UWord tmp;
+ UWord tmp =3D 0;
Bool ok;
if (arg1 =3D=3D 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 +=3D VKI_SHMLBA - VKI_PAGE_SIZE;
}
- tmp =3D VG_(am_get_advisory_client_simple)(0, segmentSize, &ok);
+ //tmp =3D VG_(am_get_advisory_client_simple)(0, segmentSize, &ok);
+ ok=3D0; /* skipping the addr advising logic above */
if (ok) {
if (VKI_SHMLBA > VKI_PAGE_SIZE) {
arg1 =3D 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 =3D VG_ROUNDDN(ARG2, VKI_SHMLBA);
#endif
arg2tmp =3D ML_(generic_PRE_sys_shmat)(tid, ARG1,ARG2,ARG3);
- if (arg2tmp =3D=3D 0)
+ if (arg2tmp =3D=3D 0 && ARG2 !=3D 0) /* skipping error condition if s=
hmaddr
is passed as 0 */
SET_STATUS_Failure( VKI_EINVAL );
else
ARG2 =3D 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=E2=80=AFAM kiran hardas <[email protected]> =
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 =3D shmat(shmid, NULL, 0); /* where data is a struct poin=
ter
> 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 =3D 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 fro=
m
> application code, in function VG_(am_get_advisory_client_simple) i can se=
e
> 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 sa=
me
> 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, shmc=
tl
> arguments may not be proper in strace, can be ignored)
>
> $/var/run/strace -p 5743 -e
> trace=3Dmmap,munmap,brk,shmctl,shmget,shmat,shmdt,mprotect
> ...
> shmget(0x987c4f, 131072, 0666) =3D 0
> shmctl(0, IPC_STAT, {shm_perm=3D{uid=3D0, gid=3D0, mode=3D0140470, key=3D=
9993295,
> cuid=3D438, cgid=3D131072}, shm_segsz=3D76, shm_cpid=3D2285489664,
> shm_lpid=3D1477341557, shm_nattch=3D1477341539, shm_atime=3D0,
> shm_dtime=3D2285489616, shm_ctime=3D1}) =3D 0
> shmat(0, 0x1fc15000, 0) =3D 0x1fc15000
> shmget(0x12940, 2190532, 0666) =3D 1
> shmctl(1, IPC_STAT, {shm_perm=3D{uid=3D0, gid=3D0, mode=3D0666, key=3D760=
96, cuid=3D0,
> cgid=3D0}, shm_segsz=3D2190532, shm_cpid=3D2504, shm_lpid=3D5825, shm_nat=
tch=3D78,
> shm_atime=3D1743438136, shm_dtime=3D1743438136, shm_ctime=3D1743437461}) =
=3D 0
> shmctl(1, IPC_STAT, {shm_perm=3D{uid=3D0, gid=3D0, mode=3D0140470, key=3D=
76096,
> cuid=3D438, cgid=3D2190532}, shm_segsz=3D78, shm_cpid=3D2285489664,
> shm_lpid=3D1477341557, shm_nattch=3D1477341539, shm_atime=3D0,
> shm_dtime=3D2285489616, shm_ctime=3D1}) =3D 0
> shmat(1, 0x1fc15000, 0) =3D -1 EINVAL (Invalid argument)
> shmget(0x98d60, 2190532, IPC_CREAT|0644) =3D 3
> shmctl(3, IPC_STAT, {shm_perm=3D{uid=3D0, gid=3D0, mode=3D000, key=3D6260=
16,
> cuid=3D420, cgid=3D2190532}, shm_segsz=3D0, shm_cpid=3D2285489664,
> shm_lpid=3D1477341557, shm_nattch=3D1477341539, shm_atime=3D0,
> shm_dtime=3D2285489616, shm_ctime=3D1}) =3D 0
> shmat(3, 0x1fc15000, 0) =3D -1 EINVAL (Invalid argument)
> +++ exited with 1 +++
>
> my system values:
> PAGE_SIZE =3D 4096 =3D 4kB
> SHMLBA =3D 4096 =3D 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 issu=
e.
> 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 versio=
n
> 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=E2=80=AFAM John Reiser <[email protected]=
> wrote:
>
>> > $ /var/run/strace -p 5564 -e shmat
>> > /var/run/strace: Process 5564 attached
>> > /var/run/strace: [ Process PID=3D5564 runs in 32 bit mode. ]
>> > shmat(0, 0x1fc15000, 0) =3D 0x1fc15000
>> > shmat(1, 0x1fc15000, 0) =3D -1 EINVAL (Invalid argumen=
t)
>> > shmat(3, 0x1fc15000, 0) =3D -1 EINVAL (Invalid argumen=
t)
>>
>> 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=3Dmemory", or "-e trace=3Dshmat,shmd=
t,
>> shmctl,shmget" to see more information.
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>
--0000000000004ebd7d0632bda9b5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Team,<div><br></div><div>I haven't received any sug=
gestion or advice to my shmat valgrind wrapper behaviour mentioned in previ=
ous mail.</div><div>To proceed ahead I have commented the call to VG_(am_ge=
t_advisory_client_simple) function if shmaddr argument value is passed as 0=
.</div><div>With this the shmaddr value if 0, will be passed to actual shma=
t syscall as it is and the kernel=C2=A0then provides an address for attach.=
=C2=A0</div><div>Have pasted the diff below for reference.</div><div><br></=
div><div><br></div><div><font color=3D"#76a5af">--- a/valgrind/coregrind/m_=
syswrap/syswrap-generic.c</font><br><font color=3D"#76a5af">+++ b/valgrind/=
coregrind/m_syswrap/syswrap-generic.c</font><br><font color=3D"#76a5af">@@ =
-2052,7 +2052,7 @@ ML_(generic_PRE_sys_shmat) ( ThreadId tid,</font><br><fo=
nt color=3D"#76a5af">=C2=A0{</font><br><font color=3D"#76a5af">=C2=A0 =C2=
=A0 /* void *shmat(int shmid, const void *shmaddr, int shmflg); */</font><b=
r><font color=3D"#76a5af">=C2=A0 =C2=A0 SizeT =C2=A0segmentSize =3D get_shm=
_size ( arg0 );</font><br><font color=3D"#990000">- =C2=A0 UWord tmp;</font=
><br><font color=3D"#38761d">+ =C2=A0 UWord tmp =3D 0;</font><br><font colo=
r=3D"#76a5af">=C2=A0 =C2=A0 Bool =C2=A0ok;</font><br><font color=3D"#76a5af=
">=C2=A0 =C2=A0 if (arg1 =3D=3D 0) {</font><br><font color=3D"#76a5af">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0/* arm-linux only: work around the fact that</font>=
<br><font color=3D"#76a5af">@@ -2067,7 +2067,8 @@ ML_(generic_PRE_sys_shmat=
) ( ThreadId tid,</font><br><font color=3D"#76a5af">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0if (VKI_SHMLBA > VKI_PAGE_SIZE) {</font><br><font color=3D"#76a5af=
">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 segmentSize +=3D VKI_SHMLBA - VKI_PAGE=
_SIZE;</font><br><font color=3D"#76a5af">=C2=A0 =C2=A0 =C2=A0 =C2=A0}</font=
><br><font color=3D"#990000">- =C2=A0 =C2=A0 =C2=A0tmp =3D VG_(am_get_advis=
ory_client_simple)(0, segmentSize, &ok);</font><br><font color=3D"#3876=
1d">+ =C2=A0 =C2=A0 =C2=A0//tmp =3D VG_(am_get_advisory_client_simple)(0, s=
egmentSize, &ok);<br>+ =C2=A0 =C2=A0 =C2=A0ok=3D0; /* skipping the addr=
advising logic above */</font><br><font color=3D"#76a5af">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0if (ok) {</font><br><font color=3D"#76a5af">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 if (VKI_SHMLBA > VKI_PAGE_SIZE) {</font><br><font colo=
r=3D"#76a5af">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg1 =3D VG_R=
OUNDUP(tmp, VKI_SHMLBA);</font><br><font color=3D"#76a5af">diff --git a/val=
grind/coregrind/m_syswrap/syswrap-linux.c b/valgrind/coregrind/m_syswrap/sy=
swrap-linux.c</font><br><font color=3D"#76a5af">index 8b23c3e..8184605 1006=
44</font><br><font color=3D"#76a5af">--- a/valgrind/coregrind/m_syswrap/sys=
wrap-linux.c</font><br><font color=3D"#76a5af">+++ b/valgrind/coregrind/m_s=
yswrap/syswrap-linux.c</font><br><font color=3D"#76a5af">@@ -5099,7 +5099,7=
@@ PRE(sys_shmat)</font><br><font color=3D"#76a5af">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0ARG2 =3D VG_ROUNDDN(ARG2, VKI_SHMLBA);</font><br><font color=3D"#76a5=
af">=C2=A0#endif</font><br><font color=3D"#76a5af">=C2=A0 =C2=A0 arg2tmp =
=3D ML_(generic_PRE_sys_shmat)(tid, ARG1,ARG2,ARG3);</font><br><font color=
=3D"#990000">- =C2=A0 if (arg2tmp =3D=3D 0)</font><br><font color=3D"#38761=
d">+ =C2=A0 if (arg2tmp =3D=3D 0 =C2=A0&& ARG2 !=3D 0) =C2=A0/* ski=
pping error condition if shmaddr is passed as 0 */</font><br><font color=3D=
"#76a5af">=C2=A0 =C2=A0 =C2=A0 =C2=A0SET_STATUS_Failure( VKI_EINVAL );</fon=
t><br><font color=3D"#76a5af">=C2=A0 =C2=A0 else</font><br><font color=3D"#=
76a5af">=C2=A0 =C2=A0 =C2=A0 =C2=A0ARG2 =3D arg2tmp; =C2=A0// used in POST<=
/font><br></div><div><font color=3D"#990000"><br></font></div><div><font co=
lor=3D"#000000">Would request your advice if this change is fine and would =
not affect the valgrind working.</font></div><div><font color=3D"#000000">W=
ith this change, my shmat functions calls are working fine as different=C2=
=A0adresses are picked up for attach.</font></div><div><font color=3D"#0000=
00">But I am not able to verify if there will be any ill-effects of this ch=
ange on the entire application working under valgrind.</font></div><div><fo=
nt color=3D"#000000">Would appreciate any kind of insights or suggestions.=
=C2=A0</font><span style=3D"color:rgb(0,0,0)">Thanks in advance.</span></di=
v><div><font color=3D"#000000"><br></font></div><div><font color=3D"#000000=
"><br></font></div><div><font color=3D"#000000">Thanks & Regards,</font=
></div><div><font color=3D"#000000">Kiran H.</font></div><div><font color=
=3D"#990000"><br></font></div></div><br><div class=3D"gmail_quote gmail_quo=
te_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 6, 2025 at =
12:34=E2=80=AFAM kiran hardas <<a href=3D"mailto:[email protected]">kh=
[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr">Hi Team,<div><br></div><div>Thanks John f=
or your inputs. I have got a few more observations on shmat failure (invali=
d argument error) under valgrind after debugging by adding logs.</div><div>=
<br></div><div>As i mentioned earlier, my application code is calling shmat=
as below (verifed the arguments)</div><div><br></div><div><span style=3D"c=
olor:rgb(80,0,80)">data =3D shmat(shmid, NULL, 0);=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 /* where data is a struct=C2=A0</span><span style=3D"colo=
r:rgb(80,0,80)">pointer and shmaddr is passed as NULL */</span></div><div><=
br></div><div>I can see the shmat call is intercepted by valgrind syscall w=
rapper for shmat. This happened after i added all 4 shm functions (shmget, =
shmat, shmdt, shmctl) entries in=C2=A0<span style=3D"color:rgb(80,0,80)">co=
regrind/m_syswrap/syswrap-x8</span><span style=3D"color:rgb(80,0,80)">6-lin=
ux.c</span><font color=3D"#000000">=C2=A0which were missing earlier.</font>=
=C2=A0There are following wrapper functions for shmat function call</div><d=
iv><br></div><div>PRE(sys_shmget)=C2=A0</div><div>=C2=A0 =C2=A0 ML_(generic=
_PRE_sys_shmat)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0tmp =3D VG_(am_g=
et_advisory_client_simple)(0, segmentSize, &ok);=C2=A0 =C2=A0 =C2=A0// =
this is advising address and overriding=C2=A0my NULL</div><div><br></div><d=
iv>POST(sys_shmat)</div><div>=C2=A0 =C2=A0 ML_(generic_POST_sys_shmat)</div=
><div><br></div><div>Even though i am passing NULL as shmaddr while calling=
shmat function from application code, in function VG_(am_get_advisory_clie=
nt_simple) i can see an address (in my case 0x1fc15000) is advised to be us=
ed for shmat overriding the NULL passed by my application. This works succe=
ssfully for the first shmat attach, but later attaches=C2=A0for shmat=C2=A0=
are failing. This same address is advised by this function for successive s=
hmat calls resulting in failure with invalid argument as that address is al=
ready used for first attach shmat call. This is happening even though i am =
attaching different to shm segment id but with same process.</div><div><br>=
</div><div>I am not clear why is it advising same address for attach and ne=
ed some help in understanding and resolving this issue.</div><div><br></div=
><div>I am pasting strace output for reference showing shmget and shmat fun=
ctions calls. Here we can see shmget calls are successful but shmat is goin=
g with same address for all its calls. ( in below strace output, shmctl arg=
uments may not be proper in strace, can be ignored)</div><div><br></div><di=
v><span style=3D"background-color:rgb(255,255,255)"><font color=3D"#990000"=
>$/var/run/strace -p 5743 -e trace=3Dmmap,munmap,brk,shmctl,shmget,shmat,sh=
mdt,mprotect</font></span><br></div><div><span style=3D"background-color:rg=
b(255,255,255)"><font color=3D"#990000">...</font></span></div><div><font c=
olor=3D"#990000"><span style=3D"background-color:rgb(182,215,168)">shmget</=
span>(0x987c4f, <span style=3D"background-color:rgb(255,217,102)">131072</s=
pan>, 0666) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 0<br>shmctl(0, IPC_STAT, =
{shm_perm=3D{uid=3D0, gid=3D0, mode=3D0140470, key=3D9993295, cuid=3D438, c=
gid=3D131072}, shm_segsz=3D76, shm_cpid=3D2285489664, shm_lpid=3D1477341557=
, shm_nattch=3D1477341539, shm_atime=3D0, shm_dtime=3D2285489616, shm_ctime=
=3D1}) =3D 0<br><span style=3D"background-color:rgb(234,153,153)">shmat</sp=
an>(0, <span style=3D"background-color:rgb(159,197,232)">0x1fc15000</span>,=
0) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x1fc15000<=
br><span style=3D"background-color:rgb(182,215,168)">shmget</span>(0x12940,=
<span style=3D"background-color:rgb(255,217,102)">2190532</span>, 0666) =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 1<br>shmctl(1, IPC_STAT, {shm_perm=3D=
{uid=3D0, gid=3D0, mode=3D0666, key=3D76096, cuid=3D0, cgid=3D0}, shm_segsz=
=3D2190532, shm_cpid=3D2504, shm_lpid=3D5825, shm_nattch=3D78, shm_atime=3D=
1743438136, shm_dtime=3D1743438136, shm_ctime=3D1743437461}) =3D 0<br>shmct=
l(1, IPC_STAT, {shm_perm=3D{uid=3D0, gid=3D0, mode=3D0140470, key=3D76096, =
cuid=3D438, cgid=3D2190532}, shm_segsz=3D78, shm_cpid=3D2285489664, shm_lpi=
d=3D1477341557, shm_nattch=3D1477341539, shm_atime=3D0, shm_dtime=3D2285489=
616, shm_ctime=3D1}) =3D 0<br><span style=3D"background-color:rgb(234,153,1=
53)">shmat</span>(1, <span style=3D"background-color:rgb(159,197,232)">0x1f=
c15000</span>, 0) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=3D -1 EINVAL (Invalid argument)<br><span style=3D"background-color:rgb(182=
,215,168)">shmget</span>(0x98d60, <span style=3D"background-color:rgb(255,2=
17,102)">2190532</span>, IPC_CREAT|0644) =3D 3<br>shmctl(3, IPC_STAT, {shm_=
perm=3D{uid=3D0, gid=3D0, mode=3D000, key=3D626016, cuid=3D420, cgid=3D2190=
532}, shm_segsz=3D0, shm_cpid=3D2285489664, shm_lpid=3D1477341557, shm_natt=
ch=3D1477341539, shm_atime=3D0, shm_dtime=3D2285489616, shm_ctime=3D1}) =3D=
0<br><span style=3D"background-color:rgb(234,153,153)">shmat</span>(3, <sp=
an style=3D"background-color:rgb(159,197,232)">0x1fc15000</span>, 0) =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D -1 EINVAL (Invalid ar=
gument)<br>+++ exited with 1 +++</font></div><div><br></div><div>my system =
values:</div><div>PAGE_SIZE =3D 4096 =3D 4kB</div><div>SHMLBA=C2=A0 =3D 409=
6 =3D 4kB</div><div><br></div><div>$ uname -a<br>Linux 5.4.282 #1 SMP PREEM=
PT Sat Apr 5 13:16:09 GMT 2025 x86_64 GNU/Linux<br></div><div><br></div><di=
v>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=
.</div><div>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=C2=A0<span style=3D"color:rgb(80,0,80)">syswra=
p-x8</span><span style=3D"color:rgb(80,0,80)">6-linux.c</span><font color=
=3D"#000000">=C2=A0 file. I tried with shmat with SHM_REMAP flag to overrid=
e earlier attach for same address, although it worked but that is=C2=A0not =
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 e=
arlier mails in mailchain=C2=A0with Valgrind 3.24. Thanks in advance!</font=
></div><div><font color=3D"#000000"><br></font></div><div><font color=3D"#0=
00000"><br></font></div><div><font color=3D"#000000">Thanks & Regards,<=
/font></div><div><font color=3D"#000000">Kiran H.</font></div></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 3=
0, 2025 at 2:34=E2=80=AFAM John Reiser <<a href=3D"mailto:jreiser@bitwag=
on.com" target=3D"_blank">[email protected]</a>> wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">> $ /var/run/strace -p 556=
4 -e shmat<br>
> /var/run/strace: Process 5564 attached<br>
> /var/run/strace: [ Process PID=3D5564 runs in 32 bit mode. ]<br>
> shmat(0, 0x1fc15000, 0) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =3D 0x1fc15000<br>
> shmat(1, 0x1fc15000, 0) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =3D -1 EINVAL (Invalid argument)<br>
> shmat(3, 0x1fc15000, 0) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =3D -1 EINVAL (Invalid argument)<br>
<br>
Please check the documentation which can be read in the output from<br>
running the shell command "man 2 shmat".=C2=A0 Each of the three =
arguments<br>
to shmat() is an input value that is specified by your program.<br>
So in this case, your program has specified the same value 0x1fc15000<br>
to three separate calls of shmat(), which requests that the shared<br>
memory segments 0, 1, and 3 be attached sequentially at the same<br>
address in the address space of the process, replacing the previous<br>
segment.=C2=A0 The documentation does not say anything about such a case.<b=
r>
Perhaps shmdt() must be called between successive shmat() which<br>
specify the same address?=C2=A0 And are the access permissions the same?<br=
>
<br>
Anyway, the address must be a multiple of SHMLBA, which might well<br>
be larger than the PAGE_SIZE.=C2=A0 The value 2*PAGE_SIZE (or 4*PAGE_SIZE)<=
br>
might be a common requirement, or perhaps SHMLBA could be much larger.-<br>
Please show the output from running the shell command "uname -a"<=
br>
which might provide some hints.=C2=A0 In particular, MIPS hardware often<br=
>
is troublesome.=C2=A0 In another process you specify the address 0x1be88000=
<br>
which is a multiple of 32KB, which is suspiciously larger than 4KB.<br>
<br>
Also, the "-e shmat" shows occurrences of only that one system ca=
ll.<br>
It might be better to use "-e trace=3Dmemory", or "-e trace=
=3Dshmat,shmdt,<br>
shmctl,shmget" to see more information.<br>
<br>
<br>
_______________________________________________<br>
Valgrind-users mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">V=
[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/valgrind-users" rel=
=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listi=
nfo/valgrind-users</a><br>
</blockquote></div>
</blockquote></div>
--0000000000004ebd7d0632bda9b5--
--===============7941610911301366627==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============7941610911301366627==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
--===============7941610911301366627==--