Re: InteractiveAugmentedIOException in CUT sc_ucalc
On 02/13/2013 05:41 PM, Stephan Bergmann wrote: On 02/13/2013 04:46 PM, Tor Lillqvist wrote: so that some catch block that should match doesn't. Isn't one typical problem that two type_infos are compared for equality by comparing the name string pointers instead of comparing the name strings with strcmp? I have seen stuff like that both in the Android and iOS ports, I think. Unfortunately it is such a complex topic that I don't recall the details. But yeah, there must be something special in his toolchain compared to that on normal Linux. Comparing just pointers is indeed how the g++ runtime traditionally behaved---though that's been changed in more recent times, to actually compare the strings. That's the reason why LO has traditionally been careful to export all the weak _ZTI* and _ZTS* symbols from all libraries. Stephan I have only very limited knowledge of the LO codebase and inner workings, and I have no clue what C++ UNO bridge is or how it works. Any hints on what I could do to debug / investigate this further would be most appreciated. /Henrik ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: InteractiveAugmentedIOException in CUT sc_ucalc
On 02/09/2013 10:04 PM, Henrik /KaarPoSoft wrote: Program received signal SIGABRT, Aborted. 0x76fcaf65 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63 63 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. #0 0x76fcaf65 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63 #1 0x76fcc3e8 in __GI_abort () at abort.c:90 #2 0x778a8edd in __gnu_cxx::__verbose_terminate_handler () at ../../../../gcc-4.7.2/libstdc++-v3/libsupc++/vterminate.cc:95 #3 0x778a6fd6 in __cxxabiv1::__terminate (handler=optimized out) at ../../../../gcc-4.7.2/libstdc++-v3/libsupc++/eh_terminate.cc:40 #4 0x778a7003 in std::terminate () at ../../../../gcc-4.7.2/libstdc++-v3/libsupc++/eh_terminate.cc:50 #5 0x778a722e in __cxxabiv1::__cxa_throw (obj=0x49f270, tinfo=optimized out, dest=optimized out) at ../../../../gcc-4.7.2/libstdc++-v3/libsupc++/eh_throw.cc:83 #6 0x756ef5fa in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) [clone .3078] () from /home/kaarpux/kaarpux/linux/build/opt/libreoffice-4.0.0.3/solver/unxlngx6.pro/lib/libgcc3_uno.so #7 0x756eb31c in cpp_vtable_call () from /home/kaarpux/kaarpux/linux/build/opt/libreoffice-4.0.0.3/solver/unxlngx6.pro/lib/libgcc3_uno.so #8 0x756f0a1e in privateSnippetExecutor () at /home/kaarpux/kaarpux/linux/build/opt/libreoffice-4.0.0.3/bridges/source/cpp_uno/gcc3_linux_x86-64/call.s:56 #9 0x77eacf1e in cppu::throwException(com::sun::star::uno::Any const) () from /home/kaarpux/kaarpux/linux/build/opt/libreoffice-4.0.0.3/solver/unxlngx6.pro/lib/libuno_cppuhelpergcc3.so.3 cppu::throwException is dirty in that it synthesizes a C++ throw expression, by using the bridge between C++ and binary UNO (bridges/source/cpp_uno/). __cxxabiv1::__cxa_throw calling std::terminate can either mean that the synthesized stuff LO passes into the C++ runtime is not acceptable at all, or that the synthesized RTTI is bad, so that some catch block that should match doesn't. Looks like the C++ UNO bridge is not working well with your toolchain, for whatever reason. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: InteractiveAugmentedIOException in CUT sc_ucalc
so that some catch block that should match doesn't. Isn't one typical problem that two type_infos are compared for equality by comparing the name string pointers instead of comparing the name strings with strcmp? I have seen stuff like that both in the Android and iOS ports, I think. Unfortunately it is such a complex topic that I don't recall the details. But yeah, there must be something special in his toolchain compared to that on normal Linux. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: InteractiveAugmentedIOException in CUT sc_ucalc
On 02/13/2013 04:46 PM, Tor Lillqvist wrote: so that some catch block that should match doesn't. Isn't one typical problem that two type_infos are compared for equality by comparing the name string pointers instead of comparing the name strings with strcmp? I have seen stuff like that both in the Android and iOS ports, I think. Unfortunately it is such a complex topic that I don't recall the details. But yeah, there must be something special in his toolchain compared to that on normal Linux. Comparing just pointers is indeed how the g++ runtime traditionally behaved---though that's been changed in more recent times, to actually compare the strings. That's the reason why LO has traditionally been careful to export all the weak _ZTI* and _ZTS* symbols from all libraries. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
