clang crashing

I am using Ubuntu 13.10 and build clang/LLVM as described here: http://clang.llvm.org/get_started.html. When using scan-build I get a lot of crash reports with output like this:

libtool: compile: /home/fsleeman/Downloads/clang/llvm/tools/clang/tools/scan-build/c+±analyzer -DHAVE_CONFIG_H -I. -I… -I…/dal/include -I…/include -I…/util/include -I…/dil/include -I…/filter/include -g -m64 -MT rcfBitmapImageContainer.lo -MD -MP -MF .deps/rcfBitmapImageContainer.Tpo -c …/dal/src/rcfBitmapImageContainer.cpp -fPIC -DPIC -o .libs/rcfBitmapImageContainer.o
0 clang++ 0x000000000314c616 llvm::sys::PrintStackTrace(_IO_FILE*) + 38
1 clang++ 0x000000000314c893
2 clang++ 0x000000000314c2e9
3 libpthread.so.0 0x00002b870d623bb0
4 clang++ 0x0000000000d14d18
5 clang++ 0x0000000001f33a9c clang::Stmt::getLocStart() const + 24
6 clang++ 0x0000000001861f70
7 clang++ 0x00000000018623dc clang::ento::PathDiagnosticLocation::createBegin(clang::Stmt const*, clang::SourceManager const&, llvm::PointerUnion<clang::LocationContext const*, clang::AnalysisDeclContext*>) + 48
8 clang++ 0x000000000177db22
9 clang++ 0x000000000177df67
10 clang++ 0x00000000017ff469
11 clang++ 0x00000000017facc7 clang::ento::CheckerManager::runCheckersForEndAnalysis(clang::ento::ExplodedGraph&, clang::ento::BugReporter&, clang::ento::ExprEngine&) + 99
12 clang++ 0x0000000001822aea clang::ento::ExprEngine::processEndWorklist(bool) + 72
13 clang++ 0x000000000181276d clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, unsigned int, llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>) + 935
14 clang++ 0x00000000016321ee
15 clang++ 0x000000000160add4
16 clang++ 0x000000000160aef4
17 clang++ 0x000000000160abca
18 clang++ 0x000000000160a2ef
19 clang++ 0x000000000160a635
20 clang++ 0x00000000010dab1e clang::ParseAST(clang::Sema&, bool, bool) + 780
21 clang++ 0x0000000000c94f6a clang::ASTFrontendAction::ExecuteAction() + 322
22 clang++ 0x0000000000c94aad clang::FrontendAction::Execute() + 205
23 clang++ 0x0000000000c67c1a clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 720
24 clang++ 0x0000000000c3732a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1026
25 clang++ 0x0000000000c2886f cc1_main(char const**, char const**, char const*, void*) + 717
26 clang++ 0x0000000000c32bc3 main + 785
27 libc.so.6 0x00002b870e274de5 __libc_start_main + 245
28 clang++ 0x0000000000c27f79
Stack dump:
0. Program arguments: /usr/local/bin/clang++ -cc1 -triple x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name rcfBitmapImageContainer.cpp -analyzer-store=region -analyzer-opt-analyze-nested-blocks -analyzer-eagerly-assume -analyzer-checker=core -analyzer-checker=unix -analyzer-checker=deadcode -analyzer-checker=cplusplus -analyzer-checker=security.insecureAPI.UncheckedReturn -analyzer-checker=security.insecureAPI.getpw -analyzer-checker=security.insecureAPI.gets -analyzer-checker=security.insecureAPI.mktemp -analyzer-checker=security.insecureAPI.mkstemp -analyzer-checker=security.insecureAPI.vfork -analyzer-output plist -w -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.23.52.20130913 -resource-dir /usr/local/bin/…/lib/clang/3.5 -D HAVE_CONFIG_H -D PIC -I . -I … -I …/dal/include -I …/include -I …/util/include -I …/dil/include -I …/filter/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/…/…/…/…/include/c++/4.8 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/…/…/…/…/include/c++/4.8/x86_64-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/…/…/…/…/include/c++/4.8/backward -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/…/…/…/…/include/x86_64-linux-gnu/c++/4.8 -internal-isystem /usr/local/include -internal-isystem /usr/local/bin/…/lib/clang/3.5/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /rdoppg/dvfTmp/fsleeman/clangTests/rcf2013/lib -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-slp -analyzer-opt-analyze-headers -analyzer-checker=debug.Stats -analyzer-output=html -o /home/fsleeman/rcf2013/results/2013-11-22-111838-11071-1 -x c++ …/dal/src/rcfBitmapImageContainer.cpp

  1. parser at end of file

Clang does give reasonable results for a small subset of source files I am trying analyze. The common link between files that crash and ones that do not is exceptions. Does clang support std::exception and do I need to enable/disable some exception feature when compiling the code?

NOTE: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

The analyzer should definitely support exceptions and std::exception, though it mostly does so by throwing up its hands rather than trying to follow the exception path. It definitely should not crash. Can you file a bug at http://llvm.org/bugs/ and attach a preprocessed version of the failing file? (Or a standalone test case.)

Sorry you’re having trouble,
Jordan

After some more tests, it looks like the errors only appear when I use the -analyze-headers option. Some of the classes I am using are templated and have implementation in the header files so I assumed I would need to use that feature to test that code. What exactly does -analyze-headers do and why would that generate those errors? If this still appear to be some sort of bug I will file a report with an example preprocessed file but I don’t want to pollute the bug list if this is not a real issue.

Thanks,
Ford

-----Jordan Rose jordan_rose@apple.com wrote: -----

Clang is never supposed to crash, so go ahead and file the bug. I wouldn’t expect -analyze-headers to cause problems, either—all it does is add those functions to the list of things to analyze—but we haven’t done too much testing with it. It’s possible the analyzer is trying to analyze the uninstantiated templates, which isn’t going to work.

Jordan