search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
27.97k stars 11.54k forks source link

Static analyzer crashes with single C++ test file #106002

Open rpfeiffer opened 3 weeks ago

rpfeiffer commented 3 weeks ago

I ran the static analyzer with the following command line:

clang++-18 --analyze -Xclang -analyzer-constraints=z3 -Wall -Werror -I. -g -O0 -march=native -std=c++20 minirng.cpp

The output was as follows:

PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump:

  1. Program arguments: clang++-18 --analyze -Xclang -analyzer-constraints=z3 -Wall -Werror -I. -g -O0 -march=native -std=c++20 minirng.cpp
  2. parser at end of file
  3. While analyzing stack:

    0 Calling std::uniform_int_distribution::_S_nd(class std::mersenne_twister_engine<unsigned long, 64, 312, 156, 31, 13043109905998158313, 29, 6148914691236517205, 17, 8202884508482404352, 37, 18444473444759240704, 43, 6364136223846793005> &, unsigned long) at line /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:307:25

    1 Calling std::uniform_int_distribution::operator()(class std::mersenne_twister_engine<unsigned long, 64, 312, 156, 31, 13043109905998158313, 29, 6148914691236517205, 17, 8202884508482404352, 37, 18444473444759240704, 43, 6364136223846793005> &, const param_type &) at line /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:193:18

    2 Calling std::uniform_int_distribution::operator()(class std::mersenne_twister_engine<unsigned long, 64, 312, 156, 31, 13043109905998158313, 29, 6148914691236517205, 17, 8202884508482404352, 37, 18444473444759240704, 43, 6364136223846793005> &) at line 171

    3 Calling main(int, char **)::(anonymous class)::operator()()

  4. /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:263:15: Error evaluating statement
  5. /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:263:15: Error evaluating statement Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var LLVM_SYMBOLIZER_PATH to point to it): 0 libLLVM-18.so.18.1 0x00007f1d0bd9f8b6 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 54 1 libLLVM-18.so.18.1 0x00007f1d0bd9d8e0 llvm::sys::RunSignalHandlers() + 80 2 libLLVM-18.so.18.1 0x00007f1d0bce9910 3 libc.so.6 0x00007f1d0ae5b050 4 libLLVM-18.so.18.1 0x00007f1d0bcbdb45 llvm::APSInt::Profile(llvm::FoldingSetNodeID&) const + 5 5 libclang-cpp.so.18.1 0x00007f1d153f9b60 clang::ento::BasicValueFactory::getValue(llvm::APSInt const&) + 80 6 libclang-cpp.so.18.1 0x00007f1d1550046f 7 libclang-cpp.so.18.1 0x00007f1d154ffe42 8 libclang-cpp.so.18.1 0x00007f1d154ff859 9 libclang-cpp.so.18.1 0x00007f1d154fdd80 10 libclang-cpp.so.18.1 0x00007f1d154fb45a 11 libclang-cpp.so.18.1 0x00007f1d15508017 clang::ento::SValBuilder::evalBinOp(llvm::IntrusiveRefCntPtr, clang::BinaryOperatorKind, clang::ento::SVal, clang::ento::SVal, clang::QualType) + 743 12 libclang-cpp.so.18.1 0x00007f1d1548c036 clang::ento::ExprEngine::VisitBinaryOperator(clang::BinaryOperator const, clang::ento::ExplodedNode, clang::ento::ExplodedNodeSet&) + 3062 13 libclang-cpp.so.18.1 0x00007f1d15479a81 clang::ento::ExprEngine::Visit(clang::Stmt const, clang::ento::ExplodedNode, clang::ento::ExplodedNodeSet&) + 8545 14 libclang-cpp.so.18.1 0x00007f1d15475b73 clang::ento::ExprEngine::ProcessStmt(clang::Stmt const, clang::ento::ExplodedNode) + 611 15 libclang-cpp.so.18.1 0x00007f1d1547589f clang::ento::ExprEngine::processCFGElement(clang::CFGElement, clang::ento::ExplodedNode, unsigned int, clang::ento::NodeBuilderContext) + 175 16 libclang-cpp.so.18.1 0x00007f1d1545c927 clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode, clang::ProgramPoint, clang::ento::WorkListUnit const&) + 551 17 libclang-cpp.so.18.1 0x00007f1d1545c491 clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const, unsigned int, llvm::IntrusiveRefCntPtr) + 1185 18 libclang-cpp.so.18.1 0x00007f1d1587e665 19 libclang-cpp.so.18.1 0x00007f1d1585e6c4 20 libclang-cpp.so.18.1 0x00007f1d13383636 clang::ParseAST(clang::Sema&, bool, bool) + 614 21 libclang-cpp.so.18.1 0x00007f1d151b4605 clang::FrontendAction::Execute() + 85 22 libclang-cpp.so.18.1 0x00007f1d1512b354 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 708 23 libclang-cpp.so.18.1 0x00007f1d1522f7ae clang::ExecuteCompilerInvocation(clang::CompilerInstance) + 750 24 clang++-18 0x000055e019eb5dfa cc1_main(llvm::ArrayRef<char const>, char const, void) + 4074 25 clang++-18 0x000055e019eb3185 26 libclang-cpp.so.18.1 0x00007f1d14de4099 27 libLLVM-18.so.18.1 0x00007f1d0bce96ac llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) + 140 28 libclang-cpp.so.18.1 0x00007f1d14de3a1e clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional>, std::__cxx11::basic_string<char, std::char_traits, std::allocator>, bool) const + 366 29 libclang-cpp.so.18.1 0x00007f1d14dabba1 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const&, bool) const + 897 30 libclang-cpp.so.18.1 0x00007f1d14dabdee clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const>>&, bool) const + 142 31 libclang-cpp.so.18.1 0x00007f1d14dc845d clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) + 333 32 clang++-18 0x000055e019eb2af4 clang_main(int, char**, llvm::ToolContext const&) + 11220 33 clang++-18 0x000055e019ebff16 main + 102 34 libc.so.6 0x00007f1d0ae4624a 35 libc.so.6 0x00007f1d0ae46305 __libc_start_main + 133 36 clang++-18 0x000055e019eafbb1 _start + 33 clang++-18: error: clang frontend command failed with exit code 139 (use -v to see invocation) Debian clang version 18.1.8 (++20240731024826+3b5b5c1ec4a3-1~exp1~20240731144843.145) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin clang++-18: note: diagnostic msg:

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang++-18: note: diagnostic msg: /tmp/minirng-896626.cpp clang++-18: note: diagnostic msg: /tmp/minirng-896626.sh clang++-18: note: diagnostic msg:

output.zip

Let me know if you need anything else.

llvmbot commented 3 weeks ago

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

Author: René Pfeiffer (rpfeiffer)

I ran the static analyzer with the following command line: clang++-18 --analyze -Xclang -analyzer-constraints=z3 -Wall -Werror -I. -g -O0 -march=native -std=c++20 minirng.cpp The output was as follows: PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: clang++-18 --analyze -Xclang -analyzer-constraints=z3 -Wall -Werror -I. -g -O0 -march=native -std=c++20 minirng.cpp 1. <eof> parser at end of file 2. While analyzing stack: #0 Calling std::uniform_int_distribution<unsigned long long>::_S_nd(class std::mersenne_twister_engine<unsigned long, 64, 312, 156, 31, 13043109905998158313, 29, 6148914691236517205, 17, 8202884508482404352, 37, 18444473444759240704, 43, 6364136223846793005> &, unsigned long) at line /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:307:25 #1 Calling std::uniform_int_distribution<unsigned long long>::operator()(class std::mersenne_twister_engine<unsigned long, 64, 312, 156, 31, 13043109905998158313, 29, 6148914691236517205, 17, 8202884508482404352, 37, 18444473444759240704, 43, 6364136223846793005> &, const param_type &) at line /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:193:18 #2 Calling std::uniform_int_distribution<unsigned long long>::operator()(class std::mersenne_twister_engine<unsigned long, 64, 312, 156, 31, 13043109905998158313, 29, 6148914691236517205, 17, 8202884508482404352, 37, 18444473444759240704, 43, 6364136223846793005> &) at line 171 #3 Calling main(int, char **)::(anonymous class)::operator()() 3. /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:263:15: Error evaluating statement 4. /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:263:15: Error evaluating statement Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 libLLVM-18.so.18.1 0x00007f1d0bd9f8b6 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 54 1 libLLVM-18.so.18.1 0x00007f1d0bd9d8e0 llvm::sys::RunSignalHandlers() + 80 2 libLLVM-18.so.18.1 0x00007f1d0bce9910 3 libc.so.6 0x00007f1d0ae5b050 4 libLLVM-18.so.18.1 0x00007f1d0bcbdb45 llvm::APSInt::Profile(llvm::FoldingSetNodeID&) const + 5 5 libclang-cpp.so.18.1 0x00007f1d153f9b60 clang::ento::BasicValueFactory::getValue(llvm::APSInt const&) + 80 6 libclang-cpp.so.18.1 0x00007f1d1550046f 7 libclang-cpp.so.18.1 0x00007f1d154ffe42 8 libclang-cpp.so.18.1 0x00007f1d154ff859 9 libclang-cpp.so.18.1 0x00007f1d154fdd80 10 libclang-cpp.so.18.1 0x00007f1d154fb45a 11 libclang-cpp.so.18.1 0x00007f1d15508017 clang::ento::SValBuilder::evalBinOp(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::BinaryOperatorKind, clang::ento::SVal, clang::ento::SVal, clang::QualType) + 743 12 libclang-cpp.so.18.1 0x00007f1d1548c036 clang::ento::ExprEngine::VisitBinaryOperator(clang::BinaryOperator const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 3062 13 libclang-cpp.so.18.1 0x00007f1d15479a81 clang::ento::ExprEngine::Visit(clang::Stmt const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 8545 14 libclang-cpp.so.18.1 0x00007f1d15475b73 clang::ento::ExprEngine::ProcessStmt(clang::Stmt const*, clang::ento::ExplodedNode*) + 611 15 libclang-cpp.so.18.1 0x00007f1d1547589f clang::ento::ExprEngine::processCFGElement(clang::CFGElement, clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) + 175 16 libclang-cpp.so.18.1 0x00007f1d1545c927 clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*, clang::ProgramPoint, clang::ento::WorkListUnit const&) + 551 17 libclang-cpp.so.18.1 0x00007f1d1545c491 clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, unsigned int, llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>) + 1185 18 libclang-cpp.so.18.1 0x00007f1d1587e665 19 libclang-cpp.so.18.1 0x00007f1d1585e6c4 20 libclang-cpp.so.18.1 0x00007f1d13383636 clang::ParseAST(clang::Sema&, bool, bool) + 614 21 libclang-cpp.so.18.1 0x00007f1d151b4605 clang::FrontendAction::Execute() + 85 22 libclang-cpp.so.18.1 0x00007f1d1512b354 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 708 23 libclang-cpp.so.18.1 0x00007f1d1522f7ae clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 750 24 clang++-18 0x000055e019eb5dfa cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 4074 25 clang++-18 0x000055e019eb3185 26 libclang-cpp.so.18.1 0x00007f1d14de4099 27 libLLVM-18.so.18.1 0x00007f1d0bce96ac llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) + 140 28 libclang-cpp.so.18.1 0x00007f1d14de3a1e clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const + 366 29 libclang-cpp.so.18.1 0x00007f1d14dabba1 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const + 897 30 libclang-cpp.so.18.1 0x00007f1d14dabdee clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const + 142 31 libclang-cpp.so.18.1 0x00007f1d14dc845d clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) + 333 32 clang++-18 0x000055e019eb2af4 clang_main(int, char**, llvm::ToolContext const&) + 11220 33 clang++-18 0x000055e019ebff16 main + 102 34 libc.so.6 0x00007f1d0ae4624a 35 libc.so.6 0x00007f1d0ae46305 __libc_start_main + 133 36 clang++-18 0x000055e019eafbb1 _start + 33 clang++-18: error: clang frontend command failed with exit code 139 (use -v to see invocation) Debian clang version 18.1.8 (++20240731024826+3b5b5c1ec4a3-1~exp1~20240731144843.145) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin clang++-18: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang++-18: note: diagnostic msg: /tmp/minirng-896626.cpp clang++-18: note: diagnostic msg: /tmp/minirng-896626.sh clang++-18: note: diagnostic msg: ******************** [output.zip](https://github.com/user-attachments/files/16741653/output.zip) Let me know if you need anything else.
EugeneZelenko commented 3 weeks ago

Could you please try 19 or main branch? https://godbolt.org should be helpful.

steakhal commented 2 weeks ago

@NagyDonat @Xazax-hun @haoNoQ WDYT of renaming -analyzer-constraints=z3 to something like -analyzer-constraints=unsupported-z3 to reflect that no maintainer is interested in fixing any of the crashes of the Z3-based solver? I never heard of anyone interested in that area, we don't have build bots testing that configuration, etc.

I think we should also disclaim this shortcoming in the docs too, even in the help text of that flag.

Should I bring this to discuss to get more visibility to this?

rpfeiffer commented 2 weeks ago

I will retry with 19 and report back. I didn't know that the z3 resolver wasn't supported. This is good to know, because I know developers who run the static analyzer with this option in test pipelines.

NagyDonat commented 2 weeks ago

WDYT of renaming -analyzer-constraints=z3 to something like -analyzer-constraints=unsupported-z3 to reflect that no maintainer is interested in fixing any of the crashes of the Z3-based solver? I never heard of anyone interested in that area, we don't have build bots testing that configuration, etc.

I completely agree, we should document that it is unsupported.

I would even suggest renaming it to deprecated-z3 and removing it in e.g. 2027 if nobody starts to support it -- we should not keep unsupported logic in the codebase indefinitely. Obviously, we should emphasize in the documentation that improving/fixing it is not deprecated (or is it? would it be possible to fix and support z3, or are there tough blocker issues?), but users should not expect stable results from it.

rpfeiffer commented 2 weeks ago

Side note: The z3 stuff is used in security research and computer science (I teach at an university for applied sciences). This was the reason why I used it in the first place. Marking z3 not supported or clearly stating that it will be removed is a good idea. I didn't realise this.

rpfeiffer commented 2 weeks ago

clang-19 (installed from Debian package) yields the same or a similar error:

PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump:

  1. Program arguments: clang++-19 --analyze -Xclang -analyzer-constraints=z3 -Wall -Werror -I. -g -O0 -march=native -std=c++20 minirng.cpp
  2. parser at end of file
  3. While analyzing stack:

    0 Calling std::uniform_int_distribution::_S_nd(class std::mersenne_twister_engine<unsigned long, 64, 312, 156, 31, 13043109905998158313, 29, 6148914691236517205, 17, 8202884508482404352, 37, 18444473444759240704, 43, 6364136223846793005> &, unsigned long) at line /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:307:25

    1 Calling std::uniform_int_distribution::operator()(class std::mersenne_twister_engine<unsigned long, 64, 312, 156, 31, 13043109905998158313, 29, 6148914691236517205, 17, 8202884508482404352, 37, 18444473444759240704, 43, 6364136223846793005> &, const param_type &) at line /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:193:18

    2 Calling std::uniform_int_distribution::operator()(class std::mersenne_twister_engine<unsigned long, 64, 312, 156, 31, 13043109905998158313, 29, 6148914691236517205, 17, 8202884508482404352, 37, 18444473444759240704, 43, 6364136223846793005> &) at line 163

    3 Calling main(int, char **)::(anonymous class)::operator()()

  4. /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:263:15: Error evaluating statement
  5. /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/uniform_int_dist.h:263:15: Error evaluating statement Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var LLVM_SYMBOLIZER_PATH to point to it): 0 libLLVM.so.19.1 0x00007fd1724b7d06 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 54 1 libLLVM.so.19.1 0x00007fd1724b59b0 llvm::sys::RunSignalHandlers() + 80 2 libLLVM.so.19.1 0x00007fd1723fdb50 3 libc.so.6 0x00007fd17105b050 4 libLLVM.so.19.1 0x00007fd1723d1695 llvm::APSInt::Profile(llvm::FoldingSetNodeID&) const + 5 5 libclang-cpp.so.19.1 0x00007fd17c1690f0 clang::ento::BasicValueFactory::getValue(llvm::APSInt const&) + 80 6 libclang-cpp.so.19.1 0x00007fd17c2716ac 7 libclang-cpp.so.19.1 0x00007fd17c2710c1 8 libclang-cpp.so.19.1 0x00007fd17c270a99 9 libclang-cpp.so.19.1 0x00007fd17c26ef70 10 libclang-cpp.so.19.1 0x00007fd17c26c69a 11 libclang-cpp.so.19.1 0x00007fd17c27af87 clang::ento::SValBuilder::evalBinOp(llvm::IntrusiveRefCntPtr, clang::BinaryOperatorKind, clang::ento::SVal, clang::ento::SVal, clang::QualType) + 743 12 libclang-cpp.so.19.1 0x00007fd17c1f9fb9 clang::ento::ExprEngine::VisitBinaryOperator(clang::BinaryOperator const, clang::ento::ExplodedNode, clang::ento::ExplodedNodeSet&) + 3401 13 libclang-cpp.so.19.1 0x00007fd17c1e77ce clang::ento::ExprEngine::Visit(clang::Stmt const, clang::ento::ExplodedNode, clang::ento::ExplodedNodeSet&) + 8830 14 libclang-cpp.so.19.1 0x00007fd17c1e3823 clang::ento::ExprEngine::ProcessStmt(clang::Stmt const, clang::ento::ExplodedNode) + 611 15 libclang-cpp.so.19.1 0x00007fd17c1e354f clang::ento::ExprEngine::processCFGElement(clang::CFGElement, clang::ento::ExplodedNode, unsigned int, clang::ento::NodeBuilderContext) + 175 16 libclang-cpp.so.19.1 0x00007fd17c1ca012 clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode, clang::ProgramPoint, clang::ento::WorkListUnit const&) + 514 17 libclang-cpp.so.19.1 0x00007fd17c1c9ba1 clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const, unsigned int, llvm::IntrusiveRefCntPtr) + 1185 18 libclang-cpp.so.19.1 0x00007fd17c602e75 19 libclang-cpp.so.19.1 0x00007fd17c5e1f8b 20 libclang-cpp.so.19.1 0x00007fd179e34fb9 clang::ParseAST(clang::Sema&, bool, bool) + 665 21 libclang-cpp.so.19.1 0x00007fd17bedc125 clang::FrontendAction::Execute() + 85 22 libclang-cpp.so.19.1 0x00007fd17be4a084 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 980 23 libclang-cpp.so.19.1 0x00007fd17bf59f0e clang::ExecuteCompilerInvocation(clang::CompilerInstance) + 702 24 clang++-19 0x000055f4961b4b69 cc1_main(llvm::ArrayRef<char const>, char const, void) + 5881 25 clang++-19 0x000055f4961b1af5 26 libclang-cpp.so.19.1 0x00007fd17badd479 27 libLLVM.so.19.1 0x00007fd1723fd8e8 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) + 136 28 libclang-cpp.so.19.1 0x00007fd17badcded clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional>, std::__cxx11::basic_string<char, std::char_traits, std::allocator>, bool) const + 365 29 libclang-cpp.so.19.1 0x00007fd17baa20d5 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const&, bool) const + 901 30 libclang-cpp.so.19.1 0x00007fd17baa233e clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const>>&, bool) const + 142 31 libclang-cpp.so.19.1 0x00007fd17babf8ac clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) + 348 32 clang++-19 0x000055f4961b1541 clang_main(int, char**, llvm::ToolContext const&) + 6769 33 clang++-19 0x000055f4961bf2f6 main + 102 34 libc.so.6 0x00007fd17104624a 35 libc.so.6 0x00007fd171046305 __libc_start_main + 133 36 clang++-19 0x000055f4961af751 _start + 33 clang++-19: error: clang frontend command failed with exit code 139 (use -v to see invocation) Debian clang version 19.1.0 (++20240815083054+4d4a4100f68d-1~exp1~20240815083209.24) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm-19/bin clang++-19: note: diagnostic msg:

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang++-19: note: diagnostic msg: /tmp/minirng-34878d.cpp clang++-19: note: diagnostic msg: /tmp/minirng-34878d.sh clang++-19: note: diagnostic msg:

diagnostic_messages.zip

rpfeiffer commented 2 weeks ago

Given the similarity and the status of the z3 support I won't test the static analyzer with clang-20. There are a lot of other options for static analysis, so the crash has low priority. I can work around z3 in my projects.

Xazax-hun commented 2 weeks ago

WDYT of renaming -analyzer-constraints=z3 to something like -analyzer-constraints=unsupported-z3 to reflect that no maintainer is interested in fixing any of the crashes of the Z3-based solver?

I agree that we should not give the false impression of something being supported. At the same time, I wish someone stepped up, so I wonder if we could word it in a way that is more like a call to action. E.g., whenever someone is using the analyzer with Z3 as the constraint solver, we could emit a warning that we are actually looking for people interested in support this?

I would even suggest renaming it to deprecated-z3 and removing it in e.g. 2027 if nobody starts to support it

We could do it in stages. First unsupported, and later deprecated. But to make it clear, this is only applicable to using z3 as the main constraint solver, right? And it is not applicable to refutation.

steakhal commented 2 weeks ago

WDYT of renaming -analyzer-constraints=z3 to something like -analyzer-constraints=unsupported-z3 to reflect that no maintainer is interested in fixing any of the crashes of the Z3-based solver? I never heard of anyone interested in that area, we don't have build bots testing that configuration, etc.

I completely agree, we should document that it is unsupported.

I would even suggest renaming it to deprecated-z3 and removing it in e.g. 2027 if nobody starts to support it -- we should not keep unsupported logic in the codebase indefinitely. Obviously, we should emphasize in the documentation that improving/fixing it is not deprecated (or is it? would it be possible to fix and support z3, or are there tough blocker issues?), but users should not expect stable results from it.

I think at bare minimum to say that it's supported, we should make it pass check-clang and have a build bot enforcing that. Now, neither of these two holds. After this, we could say that it's experimental - but definitely not production ready.

Side note: The z3 stuff is used in security research and computer science (I teach at an university for applied sciences). This was the reason why I used it in the first place. Marking z3 not supported or clearly stating that it will be removed is a good idea. I didn't realise this.

No worries. You didn't know that this is not supported. Even bug reports could be useful for people picking this up. However, at the stage it is right now, it crashes so often that I don't think there is much value tracking them. That's why I'm pushing back here. We get reports like this time to time.

WDYT of renaming -analyzer-constraints=z3 to something like -analyzer-constraints=unsupported-z3 to reflect that no maintainer is interested in fixing any of the crashes of the Z3-based solver?

I agree that we should not give the false impression of something being supported. At the same time, I wish someone stepped up, so I wonder if we could word it in a way that is more like a call to action. E.g., whenever someone is using the analyzer with Z3 as the constraint solver, we could emit a warning that we are actually looking for people interested in support this?

I believe, it could be improved to be quite fast - but likely never as fast as the range-based solver. PRs are welcomed of course.

I would even suggest renaming it to deprecated-z3 and removing it in e.g. 2027 if nobody starts to support it

We could do it in stages. First unsupported, and later deprecated. But to make it clear, this is only applicable to using z3 as the main constraint solver, right? And it is not applicable to refutation.

Z3-crosschecking (refutation) is solid.