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
