-
Notifications
You must be signed in to change notification settings - Fork 75
CON51-CPP: Falsely reports potential leaks of std::lock_guard #972
Copy link
Copy link
Closed
Labels
Difficulty-LowA false positive or false negative report which is expected to take <1 day effort to addressA false positive or false negative report which is expected to take <1 day effort to addressStardard-CERT-C++bugSomething isn't workingSomething isn't workingfalse positive/false negativeAn issue related to observed false positives or false negatives.An issue related to observed false positives or false negatives.false-positiveAn issue representing a false positive report.An issue representing a false positive report.support-sev1High urgency, continuous impact to customer business, no known workaroundHigh urgency, continuous impact to customer business, no known workarounduser-reportIssue reported by an end user of CodeQL Coding StandardsIssue reported by an end user of CodeQL Coding Standards
Metadata
Metadata
Assignees
Labels
Difficulty-LowA false positive or false negative report which is expected to take <1 day effort to addressA false positive or false negative report which is expected to take <1 day effort to addressStardard-CERT-C++bugSomething isn't workingSomething isn't workingfalse positive/false negativeAn issue related to observed false positives or false negatives.An issue related to observed false positives or false negatives.false-positiveAn issue representing a false positive report.An issue representing a false positive report.support-sev1High urgency, continuous impact to customer business, no known workaroundHigh urgency, continuous impact to customer business, no known workarounduser-reportIssue reported by an end user of CodeQL Coding StandardsIssue reported by an end user of CodeQL Coding Standards
Type
Fields
Give feedbackNo fields configured for issues without a type.
Affected rules
Description
The description of CON51-CPP recommends that users use
std::lock_guardto avoid leaking locked mutexes when an exception occurs. However, it seems that this rule was likely implemented before we supportedstd::lock_guardin ourLockProtectedControlFlowNodeclass, and it assumes all locks require a catch block. Most likely, we later added support for std::lock_guard and didn't update this rule to allowLockProtectedControlFlowNodes without catch blocks when the lock cannot leak.Example