SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
C

C static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your C code

  • All rules 315
  • Vulnerability13
  • Bug76
  • Security Hotspot19
  • Code Smell207

  • Quick Fix 19
Filtered: 6 rules found
multi-threading
    Impact
      Clean code attribute
        1. "pthread_mutex_t" should be unlocked in the reverse order they were locked

           Bug
        2. "pthread_mutex_t" should be properly initialized and destroyed

           Bug
        3. "pthread_mutex_t" should not be locked when already locked, or unlocked when already unlocked

           Bug
        4. Blocking functions should not be called inside critical sections

           Code Smell
        5. Local variables and member data should not be volatile

           Code Smell
        6. Non-reentrant POSIX functions should be replaced with their reentrant versions

           Code Smell

        "pthread_mutex_t" should be unlocked in the reverse order they were locked

        intentionality - logical
        reliability
        Bug
        • symbolic-execution
        • multi-threading

        Why is this an issue?

        How can I fix it?

        Mutexes are synchronization primitives that allow the managing of concurrency. It is a common situation to have to use multiple mutexes to protect multiple resources with different access patterns.

        In such a situation, it is crucial to define an order on the set of all mutexes:

        • This order should be strictly followed when locking mutexes.
        • The reverse order should be strictly followed when unlocking mutexes.

        Failure to do so can lead to deadlocks. i.e., situations where two or more threads are blocked forever, each holding one mutex and waiting for one held by the other(s).

        In C++, an easy way to make sure the unlocks are called in reverse order from the lock is to wrap the lock/unlock operations in an RAII class (since destructors of local variables are called in reverse order of their creation).

        If instead of pthread_mutex_t you are using std::mutex, there are other mechanisms that allow you to avoid deadlocks in that case, see S5524.

          Available In:
        • SonarQube IdeCatch issues on the fly,
          in your IDE
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          9.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use