Page MenuHomePhabricator

[tsan] Detect uses of uninitialized, destroyed and invalid mutexes

Authored by kubamracek on Mar 13 2016, 6:51 AM.



Currently, calling pthread_mutex_lock on a destroyed (or uninitialized or completely invalid) mutex will silently continue, without any TSan reports. This is because the function will return EINVAL in these cases. However, it's extremely uncommon to correctly handle failure return values from pthread_mutex_lock. In fact, I don't remember ever seeing code that even checks the return value from pthread_mutex_lock.

This patch adds a new TSan report type, ReportTypeMutexInvalidAccess, which is triggered when pthread_mutex_lock or pthread_mutex_unlock returns EINVAL (this means the mutex is invalid, uninitialized or already destroyed).

Diff Detail


Event Timeline

kubamracek updated this revision to Diff 50550.Mar 13 2016, 6:51 AM
kubamracek retitled this revision from to [tsan] Detect uses of uninitialized, destroyed and invalid mutexes.
kubamracek updated this object.
kubamracek added reviewers: dvyukov, glider, samsonov, kcc.
kubamracek added subscribers: llvm-commits, zaks.anna, filcab.
dvyukov accepted this revision.Mar 15 2016, 5:57 AM
dvyukov edited edge metadata.


My only concern is that some pthread implementations will not detect this bug and the test will fail. But I guess the bots will tell.

We probably could do the same check in pthread_mutex_destroy. But FWIW my implementation does not detect double-destroy.

This show a flaw in the interceptors. If a mutex function fails, we don't execute COMMON_INTERCEPTOR_MUTEX_LOCK/DESTROY and don't catch use-after-free on mutex accesses. Always emulating the memory access is probably the right thing to do (esp for asan).

This revision is now accepted and ready to land.Mar 15 2016, 5:57 AM
This revision was automatically updated to reflect the committed changes.