clang-tidy clang-analyzer-unix.BlockInCriticalSection false positive with std::defer_lock

[SRHMorris]

I've run into this false positive when using std::unique_lock with std::defer_lock. This is using LLVM 21.1.4.

Minimum reproducible example, real code is more complex than this:

#include <mutex>
#include <sys/socket.h> 
int main()
{
    std::mutex m;
    std::unique_lock lock(m, std::defer_lock);
    recv(0, nullptr, 0, 0);
}

Produces the following output:

.../main.cpp:8:3: error: Call to blocking function 'recv' inside of critical section [clang-analyzer-unix.BlockInCriticalSection,-warnings-as-errors]
    8 |   recv(0, nullptr, 0, 0);
      |   ^~~~~~~~~~~~~~~~~~~~~~
.../main.cpp:7:20: note: Entering critical section here
    7 |   std::unique_lock lock(m, std::defer_lock);
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~
.../main.cpp:8:3: note: Call to blocking function 'recv' inside of critical section
    8 |   recv(0, nullptr, 0, 0);
      |   ^~~~~~~~~~~~~~~~~~~~~~

Expected result is that this shouldn't produce a warning, as the mutex is unlocked at the point where recv is called.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: None (SRHMorris)

I've run into this false positive when using std::unique_lock with std::defer_lock. This is using LLVM 21.1.4.

Minimum reproducible example, real code is more complex than this:

#include <mutex>
#include <sys/socket.h> 
int main()
{
    std::mutex m;
    std::unique_lock lock(m, std::defer_lock);
    recv(0, nullptr, 0, 0);
}

Produces the following output:

.../main.cpp:8:3: error: Call to blocking function 'recv' inside of critical section [clang-analyzer-unix.BlockInCriticalSection,-warnings-as-errors]
    8 |   recv(0, nullptr, 0, 0);
      |   ^~~~~~~~~~~~~~~~~~~~~~
.../main.cpp:7:20: note: Entering critical section here
    7 |   std::unique_lock lock(m, std::defer_lock);
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~
.../main.cpp:8:3: note: Call to blocking function 'recv' inside of critical section
    8 |   recv(0, nullptr, 0, 0);
      |   ^~~~~~~~~~~~~~~~~~~~~~

Expected result is that this shouldn't produce a warning, as the mutex is unlocked at the point where recv is called.

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: None (SRHMorris)

I've run into this false positive when using std::unique_lock with std::defer_lock. This is using LLVM 21.1.4.

Minimum reproducible example, real code is more complex than this:

#include <mutex>
#include <sys/socket.h> 
int main()
{
    std::mutex m;
    std::unique_lock lock(m, std::defer_lock);
    recv(0, nullptr, 0, 0);
}

Produces the following output:

.../main.cpp:8:3: error: Call to blocking function 'recv' inside of critical section [clang-analyzer-unix.BlockInCriticalSection,-warnings-as-errors]
    8 |   recv(0, nullptr, 0, 0);
      |   ^~~~~~~~~~~~~~~~~~~~~~
.../main.cpp:7:20: note: Entering critical section here
    7 |   std::unique_lock lock(m, std::defer_lock);
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~
.../main.cpp:8:3: note: Call to blocking function 'recv' inside of critical section
    8 |   recv(0, nullptr, 0, 0);
      |   ^~~~~~~~~~~~~~~~~~~~~~

Expected result is that this shouldn't produce a warning, as the mutex is unlocked at the point where recv is called.

[gamesh411]

Thanks for reporting this.
This is indeed caused by incomplete modelling, and I have a proposed fix for this.