Re: Need support in debugging Valgrind 3.18 glibc segv error
kiran hardas <[email protected]> Fri, 25 Apr 2025 03:27:28 +0530
| Newsgroups | gmane.comp.debugging.valgrind |
|---|---|
| Message-ID | <CAPyEgmZwRjgXY42KPV=7UfkNKy=o3Z8Vufi14tPtejBc-5rzYw@mail.gmail.com> |
--===============2238370876912272899== Content-Type: multipart/alternative; boundary="00000000000069120d06338d4ea8" --00000000000069120d06338d4ea8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Team, Thanks Philippe for your response. I have now used these macros VALGRIND_MAKE_MEM_DEFINED after wherever i am attaching to the shared memory to mark it valid from valgrind perspective. These shared memory locations are anyway memsetted to 0 as part of initialisations once created. With this i don't see further invalid read errors. Is this fix/macro use fine? Thanks & Regards, Kiran H. On Wed, Apr 23, 2025 at 2:09=E2=80=AFAM Philippe Waroquiers < [email protected]> wrote: > If you use some piece of shared memory in a process X and this piece of > shared memory is > initialized by another process Y, valgrind/X has no way to know that > process Y has > initialized this memory. > > The typical solution is to have process X marking the memory as > initialized just > after it has attached to it. > > Thanks > Philippe > > On Wed, 2025-04-23 at 01:24 +0530, kiran hardas wrote: > > Hi Team, > > > > Thanks John Reiser for your observations. In continuation of further > valgrind testing, i > > am seeing below type of errors from my application code many times > (around 200-300 > > times). > > > > =3D=3D3534=3D=3D Invalid write of size 4 > > =3D=3D3534=3D=3D at 0xF5FAD71: <application backtrace> > > =3D=3D3534=3D=3D by 0xF5FAD71: <application backtrace> > > =3D=3D3534=3D=3D by 0xF1F073F: <application backtrace> > > =3D=3D3534=3D=3D Address 0xf7fb1ce4 is not stack'd, malloc'd or (recen= tly) > free'd > > > > > > The line nos. pointed by these errors are places in code where i am > using structure > > pointer variables to access structure members. This structure data is > present in shared > > memory location. On printing the structure member values using pointers > in debug logs, i > > dont see any problem with value. > > > > My suspicion is that since we are skipping address advisory logic in > valgrind wrapper > > during shmat attach call (passed with shmaddr as NULL), it is attaching > to different > > memory location provided by kernel which the valgrind may be detecting > as invalid. There > > are many similar errors coming from different parts of application code > but relating to > > the same action of structure member access from shared memory. > > > > One approach i was thinking is to suppress these invalid read errors > using suppression > > option of valgrind because i dont see any related symptom of this error= , > as in no crash > > observed (seg fault). Will it be a proper approach? Would appreciate an= y > > sugestions/advice for this issue. Or should i need to check any > particular code area or > > approach? Please do advice as it would be helpful. Thanks in advance! > > > > > > Thanks & Regards, > > Kiran H. > > > > On Tue, Apr 15, 2025 at 1:35=E2=80=AFAM John Reiser <[email protected]= om> > wrote: > > > On 4/14/25 7:13 AM, kiran hardas wrote: > > > > Hi Team, > > > > > > > > I haven't received any suggestion or advice to my shmat valgrind > wrapper > > > > behaviour mentioned in previous mail. > > > > > > > --- a/valgrind/coregrind/m_syswrap/syswrap-generic.c > > > > +++ b/valgrind/coregrind/m_syswrap/syswrap-generic.c > > > > @@ -2052,7 +2052,7 @@ ML_(generic_PRE_sys_shmat) ( ThreadId tid, > > > > { > > > > /* void *shmat(int shmid, const void *shmaddr, int shmflg); *= / > > > > SizeT segmentSize =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 > > > > > > In the current git source for > > > valgrind/coregrind/m_syswrap/syswrap-generic.c at function > > > ML_(generic_PRE_sys_shmat) (line 2346), I see > > > =3D=3D=3D=3D=3D > > > if (arg1 =3D=3D 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 >=3D VKI_PAGE_SIZE. Hen= ce > > > 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. */ > > > =3D=3D=3D=3D=3D > > > where "git blame" for the first two lines says > > > =3D=3D=3D=3D=3D > > > cc8ccbbfb4 coregrind/m_syswrap/syswrap-generic.c (Julian Seward > > > 2005-09-27 19:20:21 +0000 2346) if (arg1 =3D=3D 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 > > > =3D=3D=3D=3D=3D > > > but I do not see any guard that tests for arm-linux only. So I would > > > say that the current source has a bug! > > > > > > Thus your change > > > > With this change, my shmat functions calls are working fine as > different adresses > > > > are picked up for attach. > > > > > > is not only OK; it should be propagated into the official source. > > > > > > > > > > > > > > > _______________________________________________ > > > Valgrind-users mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > _______________________________________________ > > Valgrind-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > --00000000000069120d06338d4ea8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Team,<div><br></div><div>Thanks Philippe for your respo= nse. I have now used these macros=C2=A0VALGRIND_MAKE_MEM_DEFINED after wher= ever=C2=A0i am attaching to the shared memory to mark it valid from valgrin= d perspective. These shared memory locations are anyway memsetted to 0 as p= art of initialisations once created. With this i don't see further inva= lid read errors. Is this fix/macro use fine?=C2=A0=C2=A0</div><div><br></di= v><div><div style=3D""><font color=3D"#000000">Thanks & Regards,</font>= </div><div style=3D""><font color=3D"#000000">Kiran H.=C2=A0</font></div></= div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"= ltr" class=3D"gmail_attr">On Wed, Apr 23, 2025 at 2:09=E2=80=AFAM Philippe = Waroquiers <<a href=3D"mailto:[email protected]">philippe.wa= [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);= padding-left:1ex">If you use some piece of shared memory in a process X and= this piece of shared memory is<br> initialized by another process Y, valgrind/X has no way to know that proces= s Y has<br> initialized this memory.<br> <br> The typical solution is to have process X marking the memory as initialized= just<br> after it has attached to it.<br> <br> Thanks<br> Philippe<br> <br> On Wed, 2025-04-23 at 01:24 +0530, kiran hardas wrote:<br> > Hi Team,<br> > <br> > Thanks John Reiser for your observations. In continuation of further v= algrind testing, i<br> > am seeing below type of errors from my application code many times (ar= ound 200-300<br> > times).<br> > <br> > =3D=3D3534=3D=3D Invalid write of size 4<br> > =3D=3D3534=3D=3D =C2=A0 =C2=A0at 0xF5FAD71: <application backtrace&= gt;<br> > =3D=3D3534=3D=3D =C2=A0 =C2=A0by 0xF5FAD71:=C2=A0 <application back= trace><br> > =3D=3D3534=3D=3D =C2=A0 =C2=A0by 0xF1F073F:=C2=A0 <application back= trace><br> > =3D=3D3534=3D=3D =C2=A0Address 0xf7fb1ce4 is not stack'd, malloc&#= 39;d or (recently) free'd<br> > <br> > <br> > The line nos. pointed by these errors are places in code where i am us= ing structure<br> > pointer variables to access structure members. This structure data is = present in shared<br> > memory location. On printing the structure member values using pointer= s in debug logs, i<br> > dont see any problem with value.<br> > <br> > My suspicion=C2=A0is that since we are skipping address=C2=A0advisory = logic in valgrind wrapper<br> > during shmat attach call (passed with shmaddr as NULL), it is attachin= g to different<br> > memory location provided by kernel which the valgrind may be=C2=A0dete= cting as invalid. There<br> > are many similar errors coming from different parts of application cod= e but relating to<br> > the same action of structure member access from shared memory.<br> > <br> > One approach i was thinking is to suppress these invalid read errors u= sing suppression<br> > option of valgrind because i dont=C2=A0see any related symptom of this= error, as in no crash<br> > observed (seg fault). Will it be a proper approach? Would appreciate a= ny<br> > sugestions/advice for this issue. Or should i need to check any partic= ular code area or<br> > approach? Please do advice as it would be helpful. Thanks in advance!<= br> > <br> > <br> > Thanks & Regards,<br> > Kiran H.=C2=A0<br> > <br> > On Tue, Apr 15, 2025 at 1:35=E2=80=AFAM John Reiser <<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>> wr= ote:<br> > > On 4/14/25 7:13 AM, kiran hardas wrote:<br> > > > Hi Team,<br> > > > <br> > > > I haven't received any suggestion or advice to my shmat = valgrind wrapper <br> > > > behaviour mentioned in previous mail.<br> > > <br> > > > --- a/valgrind/coregrind/m_syswrap/syswrap-generic.c<br> > > > +++ b/valgrind/coregrind/m_syswrap/syswrap-generic.c<br> > > > @@ -2052,7 +2052,7 @@ ML_(generic_PRE_sys_shmat) ( ThreadId = tid,<br> > > > =C2=A0 =C2=A0{<br> > > > =C2=A0 =C2=A0 =C2=A0 /* void *shmat(int shmid, const void *s= hmaddr, int shmflg); */<br> > > > =C2=A0 =C2=A0 =C2=A0 SizeT =C2=A0segmentSize =3D get_shm_siz= e ( arg0 );<br> > > > - =C2=A0 UWord tmp;<br> > > > + =C2=A0 UWord tmp =3D 0;<br> > > > =C2=A0 =C2=A0 =C2=A0 Bool =C2=A0ok;<br> > > > =C2=A0 =C2=A0 =C2=A0 if (arg1 =3D=3D 0) {<br> > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* arm-linux only: work ar= ound the fact that<br> > > <br> > > In the current git source for <br> > > valgrind/coregrind/m_syswrap/syswrap-generic.c at function <br> > > ML_(generic_PRE_sys_shmat) (line 2346), I see<br> > > =3D=3D=3D=3D=3D<br> > > =C2=A0 =C2=A0 if (arg1 =3D=3D 0) {<br> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0/* arm-linux only: work around the fac= t that<br> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VG_(am_get_advisory_client_sim= ple) produces something that is<br> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VKI_PAGE_SIZE aligned, whereas= what we want is something<br> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VKI_SHMLBA aligned, and VKI_SH= MLBA >=3D VKI_PAGE_SIZE.=C2=A0 Hence<br> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 increase the request size by V= KI_SHMLBA - VKI_PAGE_SIZE and<br> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then round the result up to th= e next VKI_SHMLBA boundary.<br> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 See bug 222545 comment 15.=C2= =A0 So far, arm-linux is the only<br> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 platform where this is known t= o be necessary. */<br> > > =3D=3D=3D=3D=3D<br> > > where "git blame" for the first two lines says<br> > > =3D=3D=3D=3D=3D<br> > > cc8ccbbfb4 coregrind/m_syswrap/syswrap-generic.c=C2=A0 =C2=A0(Jul= ian Seward <br> > > 2005-09-27 19:20:21 +0000 2346)=C2=A0 =C2=A0 if (arg1 =3D=3D 0) {= <br> > > 566a25cf7e coregrind/m_syswrap/syswrap-generic.c=C2=A0 =C2=A0(Jul= ian Seward <br> > > 2010-10-06 15:24:39 +0000 2347)=C2=A0 =C2=A0 =C2=A0 =C2=A0/* arm-= linux only: work around the <br> > > fact that<br> > > =3D=3D=3D=3D=3D<br> > > but I do not see any guard that tests for arm-linux only.=C2=A0 S= o I would<br> > > say that the current source has a bug!<br> > > <br> > > Thus your change<br> > > > With this change, my shmat functions calls are working fine = as different adresses<br> > > > are picked up for attach.<br> > > <br> > > is not only OK; it should be propagated into the official source.= <br> > > <br> > > <br> > > <br> > > <br> > > _______________________________________________<br> > > Valgrind-users mailing list<br> > > <a href=3D"mailto:[email protected]" target=3D= "_blank">[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/l= ists/listinfo/valgrind-users</a><br> > _______________________________________________<br> > Valgrind-users mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_bla= nk">[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/= listinfo/valgrind-users</a><br> <br> </blockquote></div> --00000000000069120d06338d4ea8-- --===============2238370876912272899== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2238370876912272899== 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 --===============2238370876912272899==--