Good suggestion - mail sent. Will report back here.
> On Jun 15, 2017, at 10:24 PM, Brice Goglin <brice.gog...@inria.fr> wrote: > > You can email scan-ad...@coverity.com <mailto:scan-ad...@coverity.com> to > report bugs and/or ask what's going on. > Brice > > > > > Le 16/06/2017 07:12, Gilles Gouaillardet a écrit : >> Ralph, >> >> >> my 0.02 US$ >> >> >> i noted the error message mentions 'holding lock >> "pmix_mutex_t.m_lock_pthread"', but it does not explicitly mentions >> >> 'pmix_global_lock' (!) >> >> at line 446, PMIX_WAIT_THREAD() does release 'cb.lock', which has the same >> type than 'pmix_global_lock', but is not the very same lock. >> >> so maybe coverity is being mislead by PMIX_WAIT_THREAD(), and hence the >> false positive >> >> >> if you have contacts at coverity, it would be interesting to report this >> false positive >> >> >> >> Cheers, >> >> >> Gilles >> >> >> On 6/16/2017 12:02 PM, r...@open-mpi.org <mailto:r...@open-mpi.org> wrote: >>> I’m trying to understand some recent coverity warnings, and I confess I’m a >>> little stumped - so I figured I’d ask out there and see if anyone has a >>> suggestion. This is in the PMIx repo, but it is reported as well in OMPI >>> (down in opal/mca/pmix/pmix2x/pmix). The warnings all take the following >>> form: >>> >>> ________________________________________________________________________________________________________ >>> >>> *** CID 145810: Concurrent data access violations (MISSING_LOCK) >>> /src/client/pmix_client.c: 451 in PMIx_Init() >>> 445 /* wait for the data to return */ >>> 446 PMIX_WAIT_THREAD(&cb.lock); >>> 447 rc = cb.status; >>> 448 PMIX_DESTRUCT(&cb); >>> 449 >>> 450 if (PMIX_SUCCESS == rc) { >>>>>> CID 145810: Concurrent data access violations (MISSING_LOCK) >>>>>> Accessing "pmix_globals.init_cntr" without holding lock >>>>>> "pmix_mutex_t.m_lock_pthread". Elsewhere, "pmix_globals_t.init_cntr" is >>>>>> accessed with "pmix_mutex_t.m_lock_pthread" held 10 out of 11 times. >>> 451 pmix_globals.init_cntr++; >>> 452 } else { >>> 453 PMIX_RELEASE_THREAD(&pmix_global_lock); >>> 454 return rc; >>> 455 } >>> 456 PMIX_RELEASE_THREAD(&pmix_global_lock); >>> >>> Now the odd thing is that the lock is in fact being held - it gets released >>> 5 lines lower down. However, the lock was taken nearly 100 lines above this >>> point. >>> >>> I’m therefore inclined to think that the lock somehow “slid” outside of >>> Coverity’s analysis window and it therefore thought (erroneously) that the >>> lock isn’t being held. Has anyone else seen such behavior? >>> >>> Ralph >>> >>> _______________________________________________ >>> devel mailing list >>> devel@lists.open-mpi.org <mailto:devel@lists.open-mpi.org> >>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >>> <https://rfd.newmexicoconsortium.org/mailman/listinfo/devel> >> >> _______________________________________________ >> devel mailing list >> devel@lists.open-mpi.org <mailto:devel@lists.open-mpi.org> >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >> <https://rfd.newmexicoconsortium.org/mailman/listinfo/devel> > > _______________________________________________ > devel mailing list > devel@lists.open-mpi.org <mailto:devel@lists.open-mpi.org> > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel > <https://rfd.newmexicoconsortium.org/mailman/listinfo/devel>
_______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
