Open deepbluev7 opened 1 year ago
Can you paste the compiler command line used?
@llvm/issue-subscribers-c-20
@llvm/issue-subscribers-clang-frontend
Can you paste the compiler command line used?
Sure, this is the snippet from the compile_commands.json
:
"command": "/usr/lib/llvm/15/bin/clang++ -DFMT_SHARED -DGSTREAMER_AVAILABLE -DNHEKO_DBUS_SYS -DQAPPLICATION_CLASS=QApplication -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB -DXCB_AVAILABLE -Dnheko_EXPORTS -I/home/nicolas/Dokumente/devel/open-source/nheko/build-clang -I/home/nicolas/Dokumente/devel/open-source/nheko -I/home/nicolas/Dokumente/devel/open-source/nheko/build-clang/nheko_autogen/include -I/home/nicolas/Dokumente/devel/open-source/nheko/src -I/home/nicolas/Dokumente/devel/open-source/nheko/includes -I/home/nicolas/Dokumente/devel/open-source/nheko/third_party/blurhash -I/home/nicolas/Dokumente/devel/open-source/nheko/third_party/cpp-httplib-0.5.12 -I/home/nicolas/Dokumente/devel/open-source/nheko/third_party/SingleApplication-3.3.2 -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtDBus -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem /home/nicolas/Dokumente/devel/open-source/mtxclient/include -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtSvg -isystem /usr/include/qt5/QtConcurrent -isystem /usr/include/qt5/QtMultimedia -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtQml -isystem /usr/include/qt5/QtQuickControls2 -isystem /usr/include/qt5/QtQuick -isystem /usr/include/qt5/QtQmlModels -isystem /usr/include/qt5/QtQuickWidgets -isystem /usr/include/gstreamer-1.0 -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -isystem /usr/lib64/libffi/include -isystem /usr/include/orc-0.4 -isystem /usr/include/libmount -isystem /usr/include/blkid -ftime-trace \t\t-Wall \t\t-Wextra \t\t-pedantic \t\t-fsized-deallocation \t\t-fdiagnostics-color=always \t\t-Wunreachable-code \t\t-Wno-attributes -Wshadow -g -fPIE -Werror -fPIC -DSPDLOG_SHARED_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -pthread -std=gnu++20 -Winvalid-pch -Xclang -include-pch -Xclang /home/nicolas/Dokumente/devel/open-source/nheko/build-clang/CMakeFiles/nheko.dir/cmake_pch.hxx.pch -Xclang -include -Xclang /home/nicolas/Dokumente/devel/open-source/nheko/build-clang/CMakeFiles/nheko.dir/cmake_pch.hxx -o CMakeFiles/nheko.dir/src/Logging.cpp.o -c /home/nicolas/Dokumente/devel/open-source/nheko/src/Logging.cpp",
"file": "/home/nicolas/Dokumente/devel/open-source/nheko/src/Logging.cpp"
I have the following source (haven't managed to reduce this further with multiple approaches, so sorry this is a bit long, maybe someone can help me?) which seems to generate the wrong assembly:
Full context: https://github.com/Nheko-Reborn/nheko/blob/8835040db61d039af4bab34e36b1e634bb9d1d1f/src/Logging.cpp
To my understanding, this is legal code and I ran this with undefined sanitizer. It however causes a crash and triggers the address sanitizer:
This is with libfmt 9.1.0 and spdlog 1.11.0.
The following assembly is generated for the
qmlMessageHandler
function:To me this looks like multiple destructor calls are generated for the temporary
shared_ptr
. You can "fix" that by getting rid of theqml()
call and accessing theshared_ptr
directly or by putting the logging calls inside a scope. From my understanding, this happens because of theconsteval
constructor for the libfmt arguments. Without the libfmt calls, the destructors seem to happen in the normal places. Specifically that part of the assembly then looks like this:Here is the Preprocessed source file.
Sorry this is a bit long. If you have any suggestions on how I could simplify this report, I will try that. We are now using this workaround: https://github.com/Nheko-Reborn/nheko/commit/4c34f4bfee284f0065f4b72c5a12649d664acf43 Original issue: https://github.com/Nheko-Reborn/nheko/issues/1292
There is a good chance I am triggering undefined behaviour, however GCC compiles it fine without warnings and I don't see any sanitizer warnings about it apart from the obvious crash from the bad code. I apologize if this is actually an issue with our code.
I tested this in Clang 15.0.7 and 14.0.6 from the Gentoo repos, haven't had a change to test 16 yet. This is with libstdc++, not libc++.