False positives related to while loops in a threaded environment (Value stored to '...' is never read)

[llvmbot]

Bugzilla Link	10863
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@tkremenek

Extended Description

Hi,

I am using scan-build (svn from 2011-09-02) to analyze c++ code and get a few false positives related to while loops in a threaded environment. Below is a code
snippet for which I get "Value stored to 'first' during its initialization is
never read" in a large projet:

---

bool first = true;

while( this->m_continue ) {
// some mutex
if( first ) {
first = false;
foo();
}
else {
bar();
}
}

[llvmbot]

assigned to @tkremenek

[llvmbot]

Hi,

I am using scan-build (svn from 2011-09-02) to analyze c++ code and get a few
false positives related to while loops in a threaded environment. Below is a
code
snippet for which I get "Value stored to 'first' during its initialization is
never read" in a large projet:

Sorry, bad copy and paste... The error message is actually:
"Value stored to 'first' is never read"
meaning it is a dead assignment and not a dead initialization.

---

bool first = true;

while( this->m_continue ) {
// some mutex
if( first ) {
first = false;
foo();
}
else {
bar();
}
}

[tkremenek]

Hi,

I am using scan-build (svn from 2011-09-02) to analyze c++ code and get a few
false positives related to while loops in a threaded environment. Below is a
code
snippet for which I get "Value stored to 'first' during its initialization is
never read" in a large projet:

---

bool first = true;

while( this->m_continue ) {
// some mutex
if( first ) {
first = false;
foo();
}
else {
bar();
}
}

This is odd. Do you have preprocessed code (an actual self-contained example) that reproduces the problem? There's got to be something else going on here besides what's obvious for this kind of problem to be happening to the analysis.

[llvmbot]

---

bool first = true;

while( this->m_continue ) {
// some mutex
if( first ) {
first = false;
foo();
}
else {
bar();
}
}

This is odd. Do you have preprocessed code (an actual self-contained example)
that reproduces the problem? There's got to be something else going on here
besides what's obvious for this kind of problem to be happening to the
analysis.

Sorry, I don't have a self-contained example yet. I'll try to make up one. If that may help, below is a code snippet closer to my actual code:

---

this->m_continue = true;
bool first = true;

try {
while( this->m_continue ) {
{ // mutex scope
boost::mutex::scoped_lock lk( this->m_mutex );

  if( first ) {
    first = false;
    this->foo();
  }
  else {
    this->bar();
  }
} // end mutex scope

if( this->canContinue() ) {
  this->doContinue();
}
else {
  boost::mutex::scoped_lock lk( this->m_mutex );
  this->m_continue = false;
}

} // end while
}
catch(...) {
this->m_continue = false;
}

[llvmbot]

test case header

[llvmbot]

test case file

[llvmbot]

I have attached a small test case that reproduces the error. It may not be minimal but is self contained.

scan-build clang++ -c scanbuild_test.cpp
[..]/scanbuild_test.cpp:29:13: warning: Value stored to 'firstFrame' is never read
firstFrame = false;
^ ~~~~~
1 warning generated.
scan-build: 1 bugs found.