mgehre/llvm-project

crash in compile

Closed this issue · 6 comments

WallStProg commented

HI again Matthias:

Hope you don't mind -- tried out latest after fix for #68, and got a different crash:

CXXOperatorCallExpr 0xca5e810 'basic_ostream<char, struct std::char_traits<char> >':'class std::basic_ostream<char>' lvalue adl
|-ImplicitCastExpr 0xca5e7f8 'basic_ostream<char, struct std::char_traits<char> > &(*)(basic_ostream<char, struct std::char_traits<char> > &, const basic_string<char, struct std::char_traits<char>, class std::allocator<char> > &)' <FunctionToPointerDecay>
| `-DeclRefExpr 0xca5e780 'basic_ostream<char, struct std::char_traits<char> > &(basic_ostream<char, struct std::char_traits<char> > &, const basic_string<char, struct std::char_traits<char>, class std::allocator<char> > &)' lvalue Function 0x8d6c438 'operator<<' 'basic_ostream<char, struct std::char_traits<char> > &(basic_ostream<char, struct std::char_traits<char> > &, const basic_string<char, struct std::char_traits<char>, class std::allocator<char> > &)'
|-DeclRefExpr 0xca5e408 'std::ostream':'class std::basic_ostream<char>' lvalue ParmVar 0xca5e070 'os' 'std::ostream &'
`-MaterializeTemporaryExpr 0xca5e768 'const std::string':'const class std::basic_string<char>' lvalue
  `-ImplicitCastExpr 0xca5e750 'const std::string':'const class std::basic_string<char>' <NoOp>
    `-CXXBindTemporaryExpr 0xca5e4a0 'std::string':'class std::basic_string<char>' (CXXTemporary 0xca5e4a0)
      `-CXXMemberCallExpr 0xca5e478 'std::string':'class std::basic_string<char>'
        `-MemberExpr 0xca5e448 '<bound member function type>' .toString 0xca52e28
          `-DeclRefExpr 0xca5e428 'const class ServiceBus::DateTime' lvalue ParmVar 0xca5e0e8 'd' 'const class ServiceBus::DateTime &'
Expression has no entry in RefersTo
UNREACHABLE executed at /shared/buildtest/clang/10.0.0/llvm-project/clang/lib/Analysis/LifetimePsetBuilder.cpp:815!

build.txt

busapp-d1a1d5.zip

mgehre commented

Thank you very much for taking the time to report this, I appreciate it!
I'll take a look it at in the next days. In the meanwhile, you might

  • Run clang/utils/creduce-clang-crash.py to create a minimal reproduce. It takes the two files from your .zip as input. It's usually the first thing I do when looking into those bugs.
  • Temporarily remove the llvm_unreachable call from LifetimePsetBuilder.cpp:815 or build with assertions turned off. That particular check is a sanity check to help us find missed cases in our analysis, but the lifetime analysis will gracefully handle its failure (when assertions are disabled) and still produce meaningful results.
mgehre commented

creduce-clang-crash.py resulted in

          ******** /home/gehre/llvm-project3/busapp-d1a1d5.reduced.cpp ********

class a {
  const int &b() const;
};
const int &a::b() const { return 0; }

Reducing the clang crash command...
Reduced command: /home/gehre/llvm-project3/build/bin/clang -cc1 -Wlifetime busapp-d1a1d5.reduced.cpp
WallStProg commented

Thanks Matthias!

As you suggested, I re-built with assertions disabled and was able to get a complete build of my project.

FWIW, I am seeing what appear to be false positives -- I know you maintain that these cannot happen, so I will do some more homework before raising any issues.

As for the reduction above, I'm not sure what it means. From the trace in build file:

0.	Program arguments: /shared/build/share/clang/10.0.0/bin/clang-10 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name busapp.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=all -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file /home/btorpey/work/bustalk/2.9.0/nsb/api/src/CMakeFiles/nsbapi.dir/busapp.cpp.gcno -resource-dir /shared/build/share/clang/10.0.0/lib/clang/10.0.0 -isystem /build/share/boost/1.59.0/include -D nsbapi_EXPORTS -D _REENTRANT -D _GLIBCXX_USE_CXX11_ABI=0 -D NDEBUG -D TIMESTEN -D LIBXML2_VERSION=2.9.2 -D JTI_NO_STD_EXCEPTION -I /opt/TimesTen/706120_64/include -I /home/btorpey/install/transact/4.0.0/release/include -I /build/share/libxml2/2.9.2/include/libxml2 -I /build/share/bt_protocols/6.1.9x/generated_include -I /home/btorpey/work/bustalk/2.9.0/admin/../nsb/api/include -I /home/btorpey/work/bustalk/2.9.0/admin/../nsb/api/msgs -internal-isystem /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7 -internal-isystem /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/x86_64-redhat-linux -internal-isystem /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/backward -internal-isystem /usr/local/include -internal-isystem /shared/build/share/clang/10.0.0/lib/clang/10.0.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -Wall -Wextra -Wformat -Wformat-nonliteral -Wno-reorder -Wno-unused-parameter -Wno-ignored-qualifiers -Wshadow -Wno-c++11-extensions -Wno-documentation-unknown-command -Wno-gnu -Wno-padded -Wno-unused-local-typedef -Wlifetime -Wlifetime-global -Wlifetime-disabled -std=gnu++98 -fdeprecated-macro -fdebug-compilation-dir /home/btorpey/work/bustalk/2.9.0/nsb/api/src -ferror-limit 19 -fmessage-length 0 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -faddrsig -o CMakeFiles/nsbapi.dir/busapp.cpp.o -x c++ /home/btorpey/work/bustalk/2.9.0/nsb/api/src/busapp.cpp 
1.	/home/btorpey/work/bustalk/2.9.0/admin/../nsb/api/include/dateTime.h:242:1: current parser token '}'
2.	/home/btorpey/work/bustalk/2.9.0/admin/../nsb/api/include/dateTime.h:10:1: parsing namespace 'ServiceBus'
3.	/home/btorpey/work/bustalk/2.9.0/admin/../nsb/api/include/dateTime.h:237:1: parsing function body 'ServiceBus::operator<<'

I believe the code being compiled is the following:

inline
std::ostream& operator<<(std::ostream& os, const DateTime& d)
{
   return os << d.toString();
}
mgehre commented

Hi, the reduction is just a note for me (or some other contributer) as it's the smallest code that produces the same crash (without any dependency on ostream or DateTime, which can be huge).

Regarding false positives: I believe the the statement local warnings (the ones you get without any additional warning flags) are free of false-positives.
This does not hold for the flow-sensitive warnings (the ones you get with -Wlifetime and similar flags). The flow-sensitive warnings produce false-positives when applied to any C++ code, but generally it should be possible to write the same code in a way that it does not produce false-positives and, hopefully, also makes the code "better".

One way to see this is that for C code, no reliable lifetime analysis is possible because the amount of abstractions is too low. Now you can write C code and compile it as C++ code, and this still does not allow proper lifetime analysis. Rewriting that same code with good abstractions allows lifetime analysis to understand what's going on and gets rid of false-positives.

But so far, no large-scale project has adopted flow sensitive -Wlifetime warnings, and our next step is really to get more real-world experience. As a result, we will tune the existing warnings and probably split them into "profiles" or "layers" where one can start with some that provide low false-positive rate and find some bugs, and later layers need a more consistent coding style to have nor false-positives but then also find more bugs.

Thus, I'm looking forward to hear about your experience of -Wlifetime on a real-world codebase!

lklein53 commented

Have you already started to take a look @mgehre ? Otherwise I would have a look

mgehre commented

Feel free! I just did the reduction.