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
