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
