Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[Philippe W. <phi...@sk...>]

Yes, VALGRIND_MAKE_MEM_DEFINED is the correct solution.
Philippe

On Fri, 2025-04-25 at 03:27 +0530, kiran hardas wrote:
> 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 AM Philippe Waroquiers <phi...@sk...>
> 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).
> > > 
> > > ==3534== Invalid write of size 4
> > > ==3534==    at 0xF5FAD71: <application backtrace>
> > > ==3534==    by 0xF5FAD71:  <application backtrace>
> > > ==3534==    by 0xF1F073F:  <application backtrace>
> > > ==3534==  Address 0xf7fb1ce4 is not stack'd, malloc'd or (recently) 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 any
> > > 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 AM John Reiser <jr...@bi...> 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 = 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.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Valgrind-users mailing list
> > > > Val...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > > _______________________________________________
> > > Valgrind-users mailing list
> > > Val...@li...
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >