Heads up: while attempting to clear out all real and imaginary helgrind errors reported during librbd teuthology test cases, I've discovered that helgrind is not compatible with std::mutex's use of PTHREAD_MUTEX_INITIALIZER -- an optimization which skips the normal calls to pthread_mutex_init / pthread_mutex_destroy. When objects using std::mutex are destructed, these mutexes remain in the helgrind internal tracking tables since pthread_mutex_destroy was not invoked. This can result in false positives and even assertion failures should a pthread_rwlock eventually be allocated at the same address of a deallocated (but not destroyed) mutex. These failures are sprinkled throughout the new async messenger code base (since it relies exclusively on std::mutex instead of Ceph's Mutex pthread wrapper) and also within osdc's Objecter. For the short-term, I think my only option will be to disable all helgrind test cases in the librbd suite since they now provide no value due to the potential for random false positives or assertion failures. Jason -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html