<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Static analyzer crashes without core.CallAndMessage"
href="https://bugs.llvm.org/show_bug.cgi?id=37056">37056</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Static analyzer crashes without core.CallAndMessage
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>6.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Static Analyzer
</td>
</tr>
<tr>
<th>Assignee</th>
<td>dcoughlin@apple.com
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jeremy.morse.llvm@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Hi,
It seems that the clang static analyser depends on the core.CallAndMessage
analyser for correctness: if it's disabled and an invalid call is encountered,
then clang crashes. Example code:
--------8<--------
class qux {
public:
~qux();
};
class foo {
public:
qux q;
};
int
main()
{
foo *bar = 0;
bar->~foo();
return 0;
}
-------->8--------
Example command lines, without core.CallAndMessage and with it are below. I've
enabled core.uninitialized just to force the analyser to run, any other
analyser could be used instead.
$ clang-6.0 -cc1 -analyze -analyzer-checker=core.uninitialized ~/test.cpp
Core dumped
$ clang-6.0 -cc1 -analyze -analyzer-checker=core.uninitialized
-analyzer-checker=core.CallAndMessage ~/test.cpp
/home/osboxes/test.cpp:15:3: warning: Called C++ object pointer is null
bar->~foo();
^~~~~~~~~~~
1 warning generated.
$
As far as I can tell, the CallAndMessage checker spots the obvious
null-dereference when calling the foo destructor, and generates an error/sink
node to terminate exploration. However, when CallAndMessage is not enabled,
clang tries to inline the bad call and crashes. The same thing happens when the
"bar" variable in the example is uninitialized. Not catching erroneous code
when checkers are disabled is expected, but it shouldn't cause clang to crash.
With assertions on, built from week-old trunk (328690), I get the following
stack trace:
clang:
/home/osboxes/llvm/projects/clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:105:
T clang::ento::SVal::castAs() const [with T = clang::ento::loc::MemRegionVal]:
Assertion `T::isKind(*this)' failed.
#0 0x0000561462f65043 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/osboxes/llvm/lib/Support/Unix/Signals.inc:398:0
#1 0x0000561462f650d6 PrintStackTraceSignalHandler(void*)
/home/osboxes/llvm/lib/Support/Unix/Signals.inc:462:0
#2 0x0000561462f632ab llvm::sys::RunSignalHandlers()
/home/osboxes/llvm/lib/Support/Signals.cpp:49:0
#3 0x0000561462f648af SignalHandler(int)
/home/osboxes/llvm/lib/Support/Unix/Signals.inc:252:0
#4 0x00007fc0e8e86150 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x13150)
#5 0x00007fc0e7daa0bb gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x370bb)
#6 0x00007fc0e7dabf5d abort (/lib/x86_64-linux-gnu/libc.so.6+0x38f5d)
#7 0x00007fc0e7da1f17 (/lib/x86_64-linux-gnu/libc.so.6+0x2ef17)
#8 0x00007fc0e7da1fc2 (/lib/x86_64-linux-gnu/libc.so.6+0x2efc2)
#9 0x0000561464e0a8d7 clang::ento::loc::MemRegionVal
clang::ento::SVal::castAs<clang::ento::loc::MemRegionVal>() const
/home/osboxes/llvm/projects/clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:106:0
#10 0x000056146524c79a
clang::ento::ExprEngine::ProcessMemberDtor(clang::CFGMemberDtor,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:1136:0
#11 0x000056146524b9db
clang::ento::ExprEngine::ProcessImplicitDtor(clang::CFGImplicitDtor,
clang::ento::ExplodedNode*)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:991:0
#12 0x0000561465249bd8
clang::ento::ExprEngine::processCFGElement(clang::CFGElement,
clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:712:0
#13 0x0000561465234be3
clang::ento::CoreEngine::HandleBlockEntrance(clang::BlockEntrance const&,
clang::ento::ExplodedNode*)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:266:0
#14 0x000056146523429e
clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*,
clang::ProgramPoint, clang::ento::WorkListUnit const&)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:163:0
#15 0x0000561465234140
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int, llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:147:0
#16 0x0000561464cf2948
clang::ento::ExprEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int)
/home/osboxes/llvm/projects/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h:168:0
#17 0x0000561464ca1ab5 (anonymous
namespace)::AnalysisConsumer::ActionExprEngine(clang::Decl*, bool,
clang::ento::ExprEngine::InliningModes, llvm::DenseSet<clang::Decl const*,
llvm::DenseMapInfo<clang::Decl const*> >*)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:753:0
#18 0x0000561464ca1bf3 (anonymous
namespace)::AnalysisConsumer::RunPathSensitiveChecks(clang::Decl*,
clang::ento::ExprEngine::InliningModes, llvm::DenseSet<clang::Decl const*,
llvm::DenseMapInfo<clang::Decl const*> >*)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:770:0
#19 0x0000561464ca184e (anonymous
namespace)::AnalysisConsumer::HandleCode(clang::Decl*, unsigned int,
clang::ento::ExprEngine::InliningModes, llvm::DenseSet<clang::Decl const*,
llvm::DenseMapInfo<clang::Decl const*> >*)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:716:0
#20 0x0000561464ca0530 (anonymous
namespace)::AnalysisConsumer::HandleDeclsCallGraph(unsigned int)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:510:0
#21 0x0000561464ca099f (anonymous
namespace)::AnalysisConsumer::runAnalysisOnTranslationUnit(clang::ASTContext&)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:556:0
#22 0x0000561464ca0bf2 (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit(clang::ASTContext&)
/home/osboxes/llvm/projects/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:587:0
#23 0x0000561465367f6c clang::ParseAST(clang::Sema&, bool, bool)
/home/osboxes/llvm/projects/clang/lib/Parse/ParseAST.cpp:171:0
#24 0x0000561463988f57 clang::ASTFrontendAction::ExecuteAction()
/home/osboxes/llvm/projects/clang/lib/Frontend/FrontendAction.cpp:1005:0
#25 0x000056146398896a clang::FrontendAction::Execute()
/home/osboxes/llvm/projects/clang/lib/Frontend/FrontendAction.cpp:908:0
#26 0x0000561463917c80
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
/home/osboxes/llvm/projects/clang/lib/Frontend/CompilerInstance.cpp:990:0
#27 0x0000561463ae1305
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
/home/osboxes/llvm/projects/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:255:0
#28 0x0000561461b7c355 cc1_main(llvm::ArrayRef<char const*>, char const*,
void*) /home/osboxes/llvm/projects/clang/tools/driver/cc1_main.cpp:221:0
#29 0x0000561461b71119 ExecuteCC1Tool(llvm::ArrayRef<char const*>,
llvm::StringRef)
/home/osboxes/llvm/projects/clang/tools/driver/driver.cpp:310:0
#30 0x0000561461b71dd9 main
/home/osboxes/llvm/projects/clang/tools/driver/driver.cpp:390:0
#31 0x00007fc0e7d941c1 __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x211c1)
#32 0x0000561461b6e77a _start (/home/osboxes/lolwat/bin/clang+0x189f77a)
One potential solution that worked for me was to add a check in
ExprEngine::shouldInlineCall, to not inline a call if it was a) to a
CXXInstanceCall and b) had an undef or constant-value CXXThisVal. Alternately,
core.CallAndMessage could be made non-optional.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>