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