You can email 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 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
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
