Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error on must-relocking of non-recursive mutex #1628

Merged
merged 4 commits into from
Nov 29, 2024
Merged

Error on must-relocking of non-recursive mutex #1628

merged 4 commits into from
Nov 29, 2024

Conversation

sim642
Copy link
Member

@sim642 sim642 commented Nov 14, 2024

mayLocks analysis can warn on it, but mutex analysis can be definite about it.

Inspired by https://gitlab.com/sosy-lab/benchmarking/sv-benchmarks/-/merge_requests/1587 which we clearly have the information for, but didn't say anything.

We cannot go to dead code in this case because we don't distinguish error-checking mutexes.

mayLocks analysis can warn on it, but mutex analysis can be definite about it.
@sim642 sim642 added the feature label Nov 14, 2024
@sim642
Copy link
Member Author

sim642 commented Nov 29, 2024

I ran it on our regression suite and found a couple of such typos as well. Apparently e141caf fixed some a long time ago, but without actually having an analysis for it for all this time.

…to TODO

On MacOS the mutex type is top because it's zero-initialized global.
On MacOS zero-initialized mutex isn't the same as a default mutex (type 0).
@sim642 sim642 merged commit ed80168 into master Nov 29, 2024
21 checks passed
@sim642 sim642 deleted the must-relock branch November 29, 2024 15:56
@sim642 sim642 added this to the v2.6.0 milestone Nov 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants