analyzer
analyzer copied to clipboard
Mutex/thread sanity analysis
While debugging some benchmark programs, I noticed they themselves contain silly bugs:
- Forgetting to unlock a mutex (e.g. at early return), which makes any following call of the function deadlock or undefined behavior: https://github.com/goblint/bench/blob/16ee6e2dfa54881be2161cb5bb6eee8cce5736d7/pthread/pfscan_comb.c#L1234-L1237.
- Unlocking a mutex, which isn't held, which is undefined behavior, e.g. forgetting to relock at the end of a loop for protected condition check: https://github.com/goblint/bench/blob/16ee6e2dfa54881be2161cb5bb6eee8cce5736d7/pthread/smtprc_comb.c#L2379-L2386. #839
- Re-initializing a locked mutex.
At least in the case of non-recursive mutexes, these issues and other similar ones might be useful to have some simple analysis for to warn about.
A related point that arose during GobCon is that joining a thread multiple times is also undefined behavior.
Other instances Helmut and I identified as easy wins to claim we are fully-fledged analyzer of concurrency bugs:
- Mutexes being used before being initialized (or after being destroyed)
- Warn when dynamically allocated mutex escapes before being initialized
- Warn if
pthread_mutex_destroy
is called while other thread that use it may still be running or it is used in the thread that called destroy after it was destroyed.
- Returning from a thread while holding a mutex (more likely to be a bug than just returning from a function while holding a mutex) #839
- Calling
pthread_cond_wait
with a mutex that is not held #839
Related #1100