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
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
