Closed WallStProg closed 5 years ago
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
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.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
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();
}
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!
Have you already started to take a look @mgehre ? Otherwise I would have a look
Feel free! I just did the reduction.
HI again Matthias:
Hope you don't mind -- tried out latest after fix for #68, and got a different crash:
build.txt
busapp-d1a1d5.zip