Closed hcho3 closed 2 weeks ago
@llvm/issue-subscribers-clang-static-analyzer
Author: Philip Hyunsu Cho (hcho3)
What clang tidy version fo you use?
Clang-tidy 19, obtained from the LLVM apt repository
Yea, I suspected. I also looked at new FPs of this kind for this checker. I havent looked at those yet in detail, but its on my plate.
I suspect is has something to do with the CallDescription changes there. @NagyDonat
In addition to my (mostly non-functional) CallDescription
changes, this checker was heavily refactored by @gamesh411, so I'm forwarding your ping to him :smile:
Currently, the modeling does not consider any modifications done through fnctl
. I think it would be feasible to support this. IMO, adding a limitation section to the docs is the best option for now, as I am working on unifying the tracking of mutex-related events during symbolic execution (via a modeling checker), and adding this case is now part of the backlog as well.
Here is a repro for a case we observed. In clang-18, we don't report the sleep
as blocking, while in clang-19 we would:
https://compiler-explorer.com/z/boos8vPTc
namespace std {
struct __mutex_base {
void lock();
};
struct mutex : __mutex_base {
void unlock();
bool try_lock();
};
template <class... MutexTypes> struct scoped_lock {
explicit scoped_lock(MutexTypes&... m);
~scoped_lock();
};
template <class MutexType> class scoped_lock<MutexType> {
public:
explicit scoped_lock(MutexType& m) : m(m) { m.lock(); }
~scoped_lock() { m.unlock(); }
private:
MutexType& m;
};
} // namespace std
extern "C" unsigned int sleep(unsigned int seconds);
int magic_number;
std::mutex m;
void fixed() {
int current;
for (int items_processed = 0; items_processed < 100; ++items_processed) {
{
std::scoped_lock guard(m);
current = magic_number;
}
sleep(current); // expected no warning
}
}
Could you please have a look if it's the same issue as the user reported in this ticket? And why do we have these reports? @gamesh411
@hcho3 could you, please, try the fix from https://github.com/llvm/llvm-project/pull/106240 to see if it addresses the false positive?
I am not familiar with the LLVM project. Is there a way to build clang-tidy
separately from other components of LLVM?
@hliao2: You need to build at least LLVM and Clang, because Clang-tidy depends on both.
FYI We accept this as a regression in clang-19, but the fix is gonna be part of clang-20 (or built from sources).
Clang-tidy generates a false positive for the
unix.BlockInCriticalSection
check when a thread that enters a critical section performs arecv()
with a non-blocking socket. This is because clang-tidy assumesfcntl
(system call to set the socket to be non-blocking) to always fail.Example: https://github.com/dmlc/xgboost/blob/0def8e0bae41e0eeeb4ee078e6e699ad6bef1986/src/collective/loop.cc#L88-L105
Error message
``` /workspace/include/xgboost/collective/socket.h:696:12: warning: Call to blocking function 'recv' inside of critical section [clang-analyzer-unix.BlockInCriticalSection] 696 | return recv(handle_, _buf, len, flags); | ^ /workspace/src/collective/loop.cc:272:5: note: Calling 'Loop::Process' 272 | this->Process(); | ^~~~~~~~~~~~~~~ /workspace/src/collective/loop.cc:154:3: note: Loop condition is true. Entering loop body 154 | while (true) { | ^ /workspace/src/collective/loop.cc:156:24: note: Calling constructor for 'unique_lockSuggested fix: Add a note in the documentation about possible false positives with non-blocking sockets.