Created attachment 37882 [details] gengal-backtrace.txt As Steffen Hau has posted in the comments on PR50394, Libreoffice's program gengal.bin fails with segmentation fault during compilation of Libreoffice itself. I have studied it more, and the problem seems with libreoffice-5.0.5.2/bridges (libgcc3_uno.so), which are "Bridges from various C++ ABIs, Java JNI, MS .Net to UNO and back.", as described by README. When I compiled libgcc3_uno.so with LTO disabled, gengal.bin ran successfully. Attaching gdb's backtrace when segmentation fault. The problem seems to be in the destructor bridges::cpp_uno::shared::CppInterfaceProxy::~CppInterfaceProxy() which is defined in bridges/source/cpp_uno/shared/cppinterfaceproxy.cxx CppInterfaceProxy::~CppInterfaceProxy() {} And also called from there from function freeCppInterfaceProxy: pThis->~CppInterfaceProxy();
There is too little information to be useful. At least please build with debugging info enabled and find out exactly what is going on. Next build with -fsanitize=undefined to see if any undefined behavior is invoked. Or try to add "-fno-lifetime-dse -fno-delete-null-pointer-checks" and see if the issue goes away.
(In reply to Markus Trippelsdorf from comment #1) Does not happen with -O0, does with -O1, -O2, -O3. When gengal.bin is compiled with -O0 -fsanitize=undefined, then in runs successfully, but the sanitizer prints some errors, attaching them in sanitizer-output.txt. With higher optimizations and -fsanitize=undefined the sanitizer prints the same, but then the program crashes. I do therefore not know if the segfault is caused by the same thing that sanitizer complains about. How can I discover if those things are related? The issue does not go away when compiled with "-fno-lifetime-dse -fno-delete-null-pointer-checks". Any ideas how to GDB it?
Created attachment 37892 [details] sanitizer-output.txt
(In reply to Marek Behun from comment #2) Do you get these "invalid vptr" errors also when you compile without -flto? If yes, then you need to fix the bug they point to in Libreoffice. You can set a breakpoint at __ubsan::Diag::~Diag in gdb to get a backtrace. CCing Honza, who, I believe, builds Libreoffice regularly with -flto.
Hi. I've just tried to build libreoffice: commit abadeb7a4a76e8ea6ec449f3ea564abf8d52a231 Author: Maxim Monastirsky <momonasmon@gmail.com> Date: Sun Feb 28 16:30:58 2016 +0200 Unused defines Change-Id: Idc31e498a7223e7827533b24ab26928e21660ff2 with latest GCC: gcc --version gcc (GCC) 6.0.0 20160308 (experimental) Works fine for both -O2 and -O2 and -flto. Unfortunately, due to: /home/marxin/Programming/libreoffice/sax/source/tools/converter.cxx: In function ‘void sax::lcl_AppendTimezone(rtl::OUStringBuffer&, sal_Int16)’: /home/marxin/Programming/libreoffice/sax/source/tools/converter.cxx:1271:47: error: invalid operands of types ‘__gnu_cxx::__enable_if<true, double>::__type {aka double}’ and ‘int’ to binary ‘operator%’ const sal_Int32 nMinutes(abs(nOffset) % 60); ~~~~~~~~~~~~~^~~~ /home/marxin/Programming/libreoffice/sax/source/tools/converter.cxx: In function ‘void sax::lcl_ConvertToUTC(sal_Int16&, sal_uInt16&, sal_uInt16&, sal_uInt16&, sal_uInt16&, sal_Int16)’: /home/marxin/Programming/libreoffice/sax/source/tools/converter.cxx:1442:55: error: invalid operands of types ‘__gnu_cxx::__enable_if<true, double>::__type {aka double}’ and ‘int’ to binary ‘operator%’ sal_Int16 const nOffsetMinutes(abs(nSourceOffset) % 60); I was unable to build 'libreoffice-5-0-5' branch. Execution of both binaries is w/o any problem. Martin