OpenOffice-4.0.1 crashes and enters file recovery mode when you attempt to format a cell in a speadsheet. Fix: None yet. How-To-Repeat: Run openoffice. Open a new speadsheet. Choose Format >> Cells. Watch it crash and burn.
I've had almost the same, but my ooo crashes while trying to format cells in existing spreadsheet, not in new. http://lists.freebsd.org/pipermail/freebsd-office/2014-January/002307.html -- SY, Marat
Responsible Changed From-To: freebsd-ports-bugs->office Over to maintainer (via the GNATS Auto Assign Tool)
New version has landed in the ports tree
I just had the very same crash with openoffice-4.1.1, built from today's ports tree. Maybe it should be reopened?
Created attachment 148146 [details] screen shot of spreadsheet with formatted cells I'm not able to reproduce the crash here. See attached screen shot. Can you get get a stack trace from the core file?
Created attachment 148153 [details] Screenshot of error message
Created attachment 148154 [details] .xls file leading to error on 'Format cells...'
It seems to depend on the spreadsheet document. It works on newly created files. Attached is an .xls on which the menu entry 'Format Cells...' (e.g. on cell A1) immediately causes an internal error (screenshot attached). It doesn't generate a stack trace or core dump but goes into its recovery mode.
Created attachment 148155 [details] screenshot of crash.xls with edited cell Hmn ... I still can't reproduce the crash. I edited crash.xls in scalc and edited cell A1. Screenshot attached. I'm guessing this has to be system specific in some way. I'm testing on 8.4-STABLE i386. Since you aren't getting a core file, soffice is probably catching the SIGSEGV and going into recovery mode. You might try this to get a stack trace: Start scalc Use ps to find the pid of soffice.bin gdb -p pid-from-last-step /usr/local/openoffice-4.1.1/openoffice4/program/soffice.bin Type "cont" at the gdb prompt Attempt Format Cells in scalc gdb should detect the SIGSEGV and prompt for input Type "bt" to get a stack trace
I'm on current. Here's the stack trace: Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000000800ee98af in __cxxabiv1::__dynamic_cast (src_ptr=0x8221fe9a0, src_type=0x805038300 <typeinfo for VclAbstractDialogFactory>, dst_type=0x80317c850 <typeinfo for SfxAbstractDialogFactory>, src2dst=-1) at ../../.././../gcc-4.8.3/libstdc++-v3/libsupc++/dyncast.cc:60 #2 0x0000000826b49553 in ScAttrDlg::ScAttrDlg () from /usr/local/openoffice-4.1.1/openoffice4/program/libscui.so #3 0x0000000826b384b8 in ScAbstractDialogFactory_Impl::CreateScAttrDlg () from /usr/local/openoffice-4.1.1/openoffice4/program/libscui.so #4 0x000000081910e6d0 in ScTabViewShell::ExecuteCellFormatDlg () from /usr/local/openoffice-4.1.1/openoffice4/program/../program/libsc.so #5 0x0000000819181a25 in ScCellShell::Execute () from /usr/local/openoffice-4.1.1/openoffice4/program/../program/libsc.so #6 0x0000000802eb3581 in SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, unsigned char) () from /usr/local/openoffice-4.1.1/openoffice4/program/libsfx.so #7 0x0000000802d6fd10 in SfxBindings::Execute_Impl(SfxRequest&, SfxSlot const*, SfxShell*) () from /usr/local/openoffice-4.1.1/openoffice4/program/libsfx.so #8 0x0000000802d7d4eb in SfxDispatchController_Impl::dispatch(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> const&) () from /usr/local/openoffice-4.1.1/openoffice4/program/libsfx.so #9 0x0000000802d7dbcc in SfxOfficeDispatch::dispatch(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () from /usr/local/openoffice-4.1.1/openoffice4/program/libsfx.so #10 0x0000000802d6fabc in SfxAsyncExec_Impl::TimerHdl(Timer*) () from /usr/local/openoffice-4.1.1/openoffice4/program/libsfx.so #11 0x0000000804b55c18 in Timer::ImplTimerCallbackProc() () ---Type <return> to continue, or q <return> to quit--- from /usr/local/openoffice-4.1.1/openoffice4/program/libvcl.so #12 0x000000080c8232b9 in GtkXLib::timeoutFn(void*) () from /usr/local/openoffice-4.1.1/openoffice4/program/libvclplug_gtk.so #13 0x000000080dd83927 in ?? () from /usr/local/lib/libglib-2.0.so.0 #14 0x000000080dd8711e in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 #15 0x000000080dd874e3 in ?? () from /usr/local/lib/libglib-2.0.so.0 #16 0x000000080dd87574 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0 #17 0x000000080c82228e in GtkXLib::Yield(bool, bool) () from /usr/local/openoffice-4.1.1/openoffice4/program/libvclplug_gtk.so #18 0x0000000804b527bd in ImplYield(bool, bool) () from /usr/local/openoffice-4.1.1/openoffice4/program/libvcl.so #19 0x0000000804b50466 in Application::Execute() () from /usr/local/openoffice-4.1.1/openoffice4/program/libvcl.so #20 0x0000000800c3abc6 in desktop::Desktop::Main () from /usr/local/openoffice-4.1.1/openoffice4/program/libsofficeapp.so #21 0x0000000804b558a7 in ImplSVMain() () from /usr/local/openoffice-4.1.1/openoffice4/program/libvcl.so #22 0x0000000804b55a06 in SVMain() () from /usr/local/openoffice-4.1.1/openoffice4/program/libvcl.so #23 0x0000000800c5c84b in soffice_main () from /usr/local/openoffice-4.1.1/openoffice4/program/libsofficeapp.so #24 0x0000000000400deb in main ()
And this is amd64.
I have the same problem - and have had it through multiple releases, with it crashing reasonably reliably under amd64 10.0-RELEASE-p7 and apache-openoffice-4.1.1_1. Note "reasonably reliably" not "reliably". I thought it crashed every time, but when I tried running it under GDB as advised, I was gobsmacked to see it didn't crash. Well, the first time anyway. It seems when run under GDB it only has about a 50% chance of crashing instead of 99%+ chance of crashing. That didn't make sense to me, so I investigated further. If my system has next to no load (most of the time - my laptop has 32G RAM, "top" currently reports 12G free and CPU 98% idle), it crashes every time. Start recompiling ports with parallelization to the max, and no crashes. This is screaming "race condition" to me. Any suggestions on what I should be doing to further investigate? Thanks!
It could be a race condition, or it could be a memory use after free bug. On HEAD, malloc() debugging is enabled, which overwrites freed memory with garbage. If the app tries to use some data structure that has been freed, then it will get garbage and might crash. On RELEASE, malloc() debugging is disabled. When the app frees some memory, malloc() might call madvise(..., MADV_FREE). In some cases the memory contents might be preserved, but in other cases the memory might get zeroed. From madvise(2): MADV_FREE Gives the VM system the freedom to free pages, and tells the system that information in the specified page range is no longer important. This is an efficient way of allowing malloc(3) to free pages anywhere in the address space, while keeping the address space valid. The next time that the page is referenced, the page might be demand zeroed, or might contain the data that was there before the MADV_FREE call. References made to that address space range will not make the VM system page the information back in from backing store until the page is modified again. What doesn't fit is that I'd expect the problem to crop up on a busy machine with a short of memory and have a better chance of working on an idle machine. I just looked more closely at stack trace in #10. Looks like a call to location 0 is triggering the SIGSEGV. Strange ... I'm reopening this PR. Unfortunately at the moment I can only test on an i386 machine running 8.4 since the hdd in my HEAD system croaked.
I'm able to reproduce this problem with apache-openoffice-4.1.1_6 on FreeBSD 10.1-STABLE, both i386 and amd64. It does not manifest itself on FreeBSD 8.4-STABLE. The problem appears to be triggered by almost any operation that pops up a dialog box. Format Cells in a spreadsheet, saving a text document, etc. Printing does not appear to be affected, but that may because it is being done by CUPS. With debug builds of both openoffice and gcc (for libstc++) and attaching to the process with gdb, I see that soffice.bin crashes with a SIGSEGV because of an apparent attempt to jump to address 0 when I attempt to save the document: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 80dc06400 (LWP 100854)] 0x0000000000000000 in ?? () The backtrace looks like this: (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000000800f584f8 in __cxxabiv1::__dynamic_cast (src_ptr=0x8267bc3c8, src_type=0x805b1fb30 <typeinfo for Window>, dst_type=0x805b1eff0 <typeinfo for SystemWindow>, src2dst=0) at ../../.././../gcc-4.8.4/libstdc++-v3/libsupc++/dyncast.cc:72 #2 0x00000008056a7bcc in Window::SetPosSizePixel (this=0x8267bc3c8, nX=0, nY=0, nWidth=637, nHeight=329, nFlags=12) at /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.1/main/vcl/source/window/window.cxx:7370 #3 0x000000080568be0a in Window::SetSizePixel (this=0x8267bc3c8, rNewSize=...) at /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.1/main/vcl/source/window/window2.cxx:1959 #4 0x000000080568bf59 in Window::SetOutputSizePixel (this=0x8267bc3c8, rNewSize=...) at /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.1/main/vcl/source/window/window2.cxx:1972 #5 0x0000000827240a3c in SvtFileDialog::AddControl (this=0x8267bc3c8, pControl=0x826a44c78, bNewLine=0 '\000') at /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.1/main/fpicker/source/office/iodlg.cxx:3338 #6 0x00000008272343d6 in SvtFileDialog::Init_Impl (this=0x8267bc3c8, nStyle=20971520) at /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.1/main/fpicker/sourc This is the relevant code for __dynamic_cast(): namespace __cxxabiv1 { // this is the external interface to the dynamic cast machinery /* sub: source address to be adjusted; nonnull, and since the * source object is polymorphic, *(void**)sub is a virtual pointer. * src: static type of the source object. * dst: destination type (the "T" in "dynamic_cast<T>(v)"). * src2dst_offset: a static hint about the location of the * source subobject with respect to the complete object; * special negative values are: * -1: no hint * -2: src is not a public base of dst * -3: src is a multiple public base type but never a * virtual base type * otherwise, the src type is a unique public nonvirtual * base type of dst at offset src2dst_offset from the * origin of dst. */ extern "C" void * __dynamic_cast (const void *src_ptr, // object started from const __class_type_info *src_type, // type of the starting object const __class_type_info *dst_type, // desired target type ptrdiff_t src2dst) // how src and dst are related { const void *vtable = *static_cast <const void *const *> (src_ptr); const vtable_prefix *prefix = adjust_pointer <vtable_prefix> (vtable, -offsetof (vtable_prefix, origin)); const void *whole_ptr = adjust_pointer <void> (src_ptr, prefix->whole_object); const __class_type_info *whole_type = prefix->whole_type; __class_type_info::__dyncast_result result; // If the whole object vptr doesn't refer to the whole object type, we're // in the middle of constructing a primary base, and src is a separate // base. This has undefined behavior and we can't find anything outside // of the base we're actually constructing, so fail now rather than // segfault later trying to use a vbase offset that doesn't exist. const void *whole_vtable = *static_cast <const void *const *> (whole_ptr); const vtable_prefix *whole_prefix = adjust_pointer <vtable_prefix> (whole_vtable, -offsetof (vtable_prefix, origin)); if (whole_prefix->whole_type != whole_type) return NULL; whole_type->__do_dyncast (src2dst, __class_type_info::__contained_public, dst_type, whole_ptr, src_type, src_ptr, result); The last two lines are 71 and 72, the location of the crash. Poking around a bit: (gdb) print whole_type $1 = (const __cxxabiv1::__class_type_info *) 0x8274647e0 <typeinfo for SvtFileDialog> (gdb) print *whole_type $2 = {<std::type_info> = { _vptr.type_info = 0x815156070 <vtable for __cxxabiv1::__vmi_class_type_info+16>, __name = 0x82724d370 <typeinfo name for SvtFileDialog> "13SvtFileDialog"}, <No data fields>} (gdb) print whole_type->__do_dyncast $3 = {bool (const __cxxabiv1::__class_type_info * const, ptrdiff_t, __cxxabiv1::__class_type_info::__sub_kind, const __cxxabiv1::__class_type_info *, const void *, const __cxxabiv1::__class_type_info *, const void *, __cxxabiv1::__class_type_info::__dyncast_result &)} 0x800f581a8 <__cxxabiv1::__class_type_info::__do_dyncast(long, __cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info const*, void const*, __c xxabiv1::__class_type_info::__dyncast_result&) The latter isn't especially helpful. I was hoping to get the function pointer and not a the prototype. Doing some disassembly: 0x0000000800f584bf <+175>: mov (%rax),%rax 0x0000000800f584c2 <+178>: add $0x38,%rax 0x0000000800f584c6 <+182>: mov (%rax),%rax 0x0000000800f584c9 <+185>: mov -0x60(%rbp),%r9 0x0000000800f584cd <+189>: mov -0x18(%rbp),%r8 0x0000000800f584d1 <+193>: mov -0x68(%rbp),%rdx 0x0000000800f584d5 <+197>: mov -0x70(%rbp),%rsi 0x0000000800f584d9 <+201>: mov -0x20(%rbp),%rdi 0x0000000800f584dd <+205>: lea -0x50(%rbp),%rcx 0x0000000800f584e1 <+209>: mov %rcx,0x8(%rsp) 0x0000000800f584e6 <+214>: mov -0x58(%rbp),%rcx 0x0000000800f584ea <+218>: mov %rcx,(%rsp) 0x0000000800f584ee <+222>: mov %rdx,%rcx 0x0000000800f584f1 <+225>: mov $0x6,%edx 0x0000000800f584f6 <+230>: callq *%rax It looks like whole_type starts out in %rax. The fetch an address at the location where whole_type points, which I believe gives us a pointer to the start of the vtable. Then we add 0x38 to that to find the entry for __dyncast(). Then we deal with the arguments for the call, adjust the stack pointer, and then call the function pointed to by the vtable entry that %rax is pointing at. Reproducing this in gdb: (gdb) print whole_type $1 = (const __cxxabiv1::__class_type_info *) 0x8274647e0 <typeinfo for SvtFileDialog> (gdb) x/a 0x8274647e0 0x8274647e0 <_ZTI13SvtFileDialog>: 0x815156070 <_ZTVN10__cxxabiv121__vmi_class_type_infoE+16> Walking through the vtable: (gdb) x/a 0x815156070 0x815156070 <_ZTVN10__cxxabiv121__vmi_class_type_infoE+16>: 0x800f5c44a <std::type_info::~type_info()> (gdb) 0x815156078 <_ZTVN10__cxxabiv121__vmi_class_type_infoE+24>: 0x800f5ceca <__cxxabiv1::__vmi_class_type_info::~__vmi_class_type_info()> (gdb) 0x815156080 <_ZTVN10__cxxabiv121__vmi_class_type_infoE+32>: 0x800f5c4a6 <std::type_info::__is_pointer_p() const> (gdb) 0x815156088 <_ZTVN10__cxxabiv121__vmi_class_type_infoE+40>: 0x800f5c4b6 <std::type_info::__is_function_p() const> (gdb) 0x815156090 <_ZTVN10__cxxabiv121__vmi_class_type_infoE+48>: 0x800f5c4c6 <std::type_info::__do_catch(std::type_info const*, void**, unsigned int) const> (gdb) 0x815156098 <_ZTVN10__cxxabiv121__vmi_class_type_infoE+56>: 0x814f52da0 (gdb) 0x8151560a0 <_ZTVN10__cxxabiv121__vmi_class_type_infoE+64>: 0x814f52d70 (gdb) 0x8151560a8: 0x0 Now 0x815156070 + 0x38 is 0x8151560a8, and sure enough we find a pointer with value 0 at that location. The offending line of code next level up is: SystemWindow *pSystemWindow = dynamic_cast< SystemWindow* >( pWindow ); What is strange is that this code works on Windows, Linux, and FreeBSD 8. It only fails on FreeBSD 10. In the case of FreeBSD, the code was compiled with the same version of lang/gcc from ports, with the same version of libstdc++, compiled with the same options, and presumably both with the same version of binutils from ports. The problem on FreeBSD 10 has persisted through multiple versions of the gcc from ports. Getting libc++ linked in as well is not the problem, because there is no sign of libc++ in the output of ldd: $ ldd /usr/local/openoffice-4.1.1/openoffice4/program/soffice.bin /usr/local/openoffice-4.1.1/openoffice4/program/soffice.bin: libuno_sal.so.3 => /usr/local/openoffice-4.1.1/openoffice4/program/libuno_sal.so.3 (0x800821000) libsofficeapp.so => /usr/local/openoffice-4.1.1/openoffice4/program/libsofficeapp.so (0x800c43000) libstdc++.so.6 => /usr/local/lib/gcc48/libstdc++.so.6 (0x800ef2000) libm.so.5 => /lib/libm.so.5 (0x80121c000) libgcc_s.so.1 => /usr/local/lib/gcc48/libgcc_s.so.1 (0x801444000) libthr.so.3 => /lib/libthr.so.3 (0x80165a000) libc.so.7 => /lib/libc.so.7 (0x80187e000) libcomphelpgcc3.so => /usr/local/openoffice-4.1.1/openoffice4/program/libcomphelpgcc3.so (0x801c29000) libuno_cppuhelpergcc3.so.3 => /usr/local/openoffice-4.1.1/openoffice4/program/libuno_cppuhelpergcc3.so.3 (0x802014000) libuno_cppu.so.3 => /usr/local/openoffice-4.1.1/openoffice4/program/libuno_cppu.so.3 (0x80230a000) libdeploymentmisc.so => /usr/local/openoffice-4.1.1/openoffice4/program/libdeploymentmisc.so (0x802569000) libdeploymentgui.uno.so => /usr/local/openoffice-4.1.1/openoffice4/program/libdeploymentgui.uno.so (0x80279f000) libi18nisolang1gcc3.so => /usr/local/openoffice-4.1.1/openoffice4/program/libi18nisolang1gcc3.so (0x802a38000) libsfx.so => /usr/local/openoffice-4.1.1/openoffice4/program/libsfx.so (0x802c40000) libsvl.so => /usr/local/openoffice-4.1.1/openoffice4/program/libsvl.so (0x80346d000) libsvt.so => /usr/local/openoffice-4.1.1/openoffice4/program/libsvt.so (0x8037fa000) libootk.so => /usr/local/openoffice-4.1.1/openoffice4/program/libootk.so (0x804031000) libtl.so => /usr/local/openoffice-4.1.1/openoffice4/program/libtl.so (0x804701000) libucbhelper4gcc3.so => /usr/local/openoffice-4.1.1/openoffice4/program/libucbhelper4gcc3.so (0x804a09000) libutl.so => /usr/local/openoffice-4.1.1/openoffice4/program/libutl.so (0x804cab000) libvcl.so => /usr/local/openoffice-4.1.1/openoffice4/program/libvcl.so (0x805061000) libvos3gcc3.so => /usr/local/openoffice-4.1.1/openoffice4/program/libvos3gcc3.so (0x805b37000) libuno_salhelpergcc3.so.3 => /usr/local/openoffice-4.1.1/openoffice4/program/libuno_salhelpergcc3.so.3 (0x805d64000) libxcr.so => /usr/local/openoffice-4.1.1/openoffice4/program/libxcr.so (0x805f68000) libsvx.so => /usr/local/openoffice-4.1.1/openoffice4/program/libsvx.so (0x806238000) libsvxcore.so => /usr/local/openoffice-4.1.1/openoffice4/program/libsvxcore.so (0x80696b000) libfwe.so => /usr/local/openoffice-4.1.1/openoffice4/program/libfwe.so (0x807618000) libsax.so => /usr/local/openoffice-4.1.1/openoffice4/program/libsax.so (0x807920000) libsb.so => /usr/local/openoffice-4.1.1/openoffice4/program/libsb.so (0x807b46000) libsot.so => /usr/local/openoffice-4.1.1/openoffice4/program/libsot.so (0x807fe3000) libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x80825f000) libbasegfx.so => /usr/local/openoffice-4.1.1/openoffice4/program/libbasegfx.so (0x8085f2000) libi18nutilgcc3.so => /usr/local/openoffice-4.1.1/openoffice4/program/libi18nutilgcc3.so (0x808997000) libjvmfwk.so.3 => /usr/local/openoffice-4.1.1/openoffice4/program/libjvmfwk.so.3 (0x808bab000) libicuuc.so.40 => /usr/local/openoffice-4.1.1/openoffice4/program/libicuuc.so.40 (0x808dd3000) libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x8090ff000) libz.so.6 => /lib/libz.so.6 (0x80933a000) libicule.so.40 => /usr/local/openoffice-4.1.1/openoffice4/program/libicule.so.40 (0x809550000) libi18npaper.so => /usr/local/openoffice-4.1.1/openoffice4/program/libi18npaper.so (0x809780000) libjvmaccessgcc3.so.3 => /usr/local/openoffice-4.1.1/openoffice4/program/libjvmaccessgcc3.so.3 (0x809988000) libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x809b91000) libdrawinglayer.so => /usr/local/openoffice-4.1.1/openoffice4/program/libdrawinglayer.so (0x809e2c000) libediteng.so => /usr/local/openoffice-4.1.1/openoffice4/program/libediteng.so (0x80a1b8000) libfwk.so => /usr/local/openoffice-4.1.1/openoffice4/program/libfwk.so (0x80a6b2000) libxo.so => /usr/local/openoffice-4.1.1/openoffice4/program/libxo.so (0x80ac42000) libavmedia.so => /usr/local/openoffice-4.1.1/openoffice4/program/libavmedia.so (0x80b3de000) liblng.so => /usr/local/openoffice-4.1.1/openoffice4/program/liblng.so (0x80b625000) libfwi.so => /usr/local/openoffice-4.1.1/openoffice4/program/libfwi.so (0x80b93d000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80bb83000) libicudata.so.40 => /usr/local/openoffice-4.1.1/openoffice4/program/libicudata.so.40 (0x80bda8000) libbz2.so.4 => /usr/lib/libbz2.so.4 (0x80cd09000) libcanvastools.so => /usr/local/openoffice-4.1.1/openoffice4/program/libcanvastools.so (0x80cf1b000) libcppcanvas.so => /usr/local/openoffice-4.1.1/openoffice4/program/libcppcanvas.so (0x80d192000) root@hoover-jail-10amd64:~ # ldd /usr/local/openoffice-4.1.1/openoffice4/program/soffice.bin | grep libc libc.so.7 => /lib/libc.so.7 (0x80187e000) libcomphelpgcc3.so => /usr/local/openoffice-4.1.1/openoffice4/program/libcomphelpgcc3.so (0x801c29000) libcanvastools.so => /usr/local/openoffice-4.1.1/openoffice4/program/libcanvastools.so (0x80cf1b000) libcppcanvas.so => /usr/local/openoffice-4.1.1/openoffice4/program/libcppcanvas.so (0x80d192000) root@hoover-jail-10amd64:~ # ldd /usr/local/openoffice-4.1.1/openoffice4/program/soffice.bin | grep libstdc libstdc++.so.6 => /usr/local/lib/gcc48/libstdc++.so.6 (0x800ef2000)
*** Bug 195563 has been marked as a duplicate of this bug. ***
I can reproduce your segfault, but the backtrace looks a bit different for me: (gdb) bt #0 0x0000000813a65fa8 in vtable for __cxxabiv1::__si_class_type_info () from /lib/libcxxrt.so.1 #1 0x0000000800eec8c8 in __cxxabiv1::__dynamic_cast (src_ptr=0x819bd23c0, src_type=0x80503f200 <typeinfo for Window>, dst_type=0x80503e790 <typeinfo for SystemWindow>, src2dst=0) at ../../.././../gcc-4.8-20150212/libstdc++-v3/libsupc++/dyncast.cc:72 #2 0x0000000804d09646 in Window::SetPosSizePixel(long, long, long, long, unsigned short) () from /usr/local/openoffice-4.1.1/openoffice4/program/libvcl.so #3 0x0000000804cfcaba in Window::SetOutputSizePixel(Size const&) () from /usr/local/openoffice-4.1.1/openoffice4/program/libvcl.so #4 0x0000000820768e35 in SvtFileDialog::AddControl () from /usr/local/openoffice-4.1.1/openoffice4/program/../program/fps_office.uno.so #5 0x0000000820771f8b in SvtFileDialog::Init_Impl () from /usr/local/openoffice-4.1.1/openoffice4/program/../program/fps_office.uno.so #6 0x00000008207742b8 in SvtFileDialog::SvtFileDialog () from /usr/local/openoffice-4.1.1/openoffice4/program/../program/fps_office.uno.so #7 0x00000008207616cd in SvtFilePicker::implCreateDialog () from /usr/local/openoffice-4.1.1/openoffice4/program/../program/fps_office.uno.so #8 0x000000082075b6cc in svt::OCommonPicker::createPicker () from /usr/local/openoffice-4.1.1/openoffice4/program/../program/fps_office.uno.so #9 0x000000082075bb9a in svt::OCommonPicker::prepareDialog () from /usr/local/openoffice-4.1.1/openoffice4/program/../program/fps_office.uno.so #10 0x000000082075bbcf in svt::OCommonPicker::execute () from /usr/local/openoffice-4.1.1/openoffice4/program/../program/fps_office.uno.so [...] E.g, it crashes while calling __do_dyncast in libsupc++, as you have shown: whole_type->__do_dyncast (src2dst, __class_type_info::__contained_public, dst_type, whole_ptr, src_type, src_ptr, result); But it ends up in libcxxrt, which is a disaster, since it does not *have* the __do_dyncast function at all. This is the most likely cause of segfaults or other random nastiness occurring. So how does soffice.bin end up with libcxxrt.so.1 being loaded? When I run ldd on my soffice.bin, there is *NO* mention of libcxxrt at all: $ ldd /usr/local/openoffice-4.1.1/openoffice4/program/soffice.bin | grep libcxxrt <nothing> Even if I 'follow' all the libraries listed by ldd, and run ldd on them, I never find a trace of libcxxrt. This can only mean that libcxxrt is loaded at runtime, via dlopen() of some external library. Setting a "catch load" in gdb finds at least one culprit: Catchpoint 1 Inferior loaded /usr/local/openoffice-4.1.1/openoffice4/program/libvclplug_gtk.so /usr/local/openoffice-4.1.1/openoffice4/program/libvclplug_gen.so /usr/local/lib/libX11.so.6 /usr/local/lib/libXext.so.6 /usr/local/lib/libSM.so.6 /usr/local/lib/libICE.so.6 /usr/local/lib/libdbus-glib-1.so.2 /usr/local/lib/libdbus-1.so.3 /usr/local/lib/libgobject-2.0.so.0 /usr/local/lib/libglib-2.0.so.0 /usr/local/lib/libintl.so.8 /usr/local/lib/libgtk-x11-2.0.so.0 /usr/local/lib/libgdk-x11-2.0.so.0 /usr/local/lib/libpangocairo-1.0.so.0 /usr/local/lib/libatk-1.0.so.0 /usr/local/lib/libcairo.so.2 /usr/local/lib/libgio-2.0.so.0 /usr/local/lib/libpangoft2-1.0.so.0 /usr/local/lib/libpango-1.0.so.0 /usr/local/lib/libfontconfig.so.1 /usr/local/lib/libgdk_pixbuf_xlib-2.0.so.0 /usr/local/lib/libgmodule-2.0.so.0 /usr/local/lib/libgdk_pixbuf-2.0.so.0 /usr/local/lib/libgthread-2.0.so.0 /usr/local/lib/libXrandr.so.2 /usr/local/lib/libXinerama.so.1 /usr/local/lib/libxcb.so.1 /usr/lib/librpcsvc.so.5 /usr/local/lib/libiconv.so.2 /usr/local/lib/libpcre.so.1 /usr/local/lib/libffi.so.6 /usr/local/lib/libXrender.so.1 /usr/local/lib/libXi.so.6 /usr/local/lib/libXcursor.so.1 /usr/local/lib/libXcomposite.so.1 /usr/local/lib/libXdamage.so.1 /usr/local/lib/libXfixes.so.3 /usr/local/lib/libharfbuzz.so.0 /usr/local/lib/libpixman-1.so.0 /usr/local/lib/libxcb-shm.so.0 /usr/local/lib/libxcb-render.so.0 /usr/local/lib/libexpat.so.1 /usr/local/lib/libXau.so.6 /usr/local/lib/libpthread-stubs.so.0 /usr/local/lib/libXdmcp.so.6 /usr/local/lib/libgraphite2.so.3 /usr/lib/libc++.so.1 /lib/libcxxrt.so.1 If I look at all the shared libraries loaded by libvclplug_gtk.so, there are the following that link to libc++ (and thus libcxxrt): /usr/local/lib/libgtk-x11-2.0.so.0 /usr/local/lib/libgdk-x11-2.0.so.0 /usr/local/lib/libpangocairo-1.0.so.0 /usr/local/lib/libpangoft2-1.0.so.0 /usr/local/lib/libharfbuzz.so.0 /usr/local/lib/libgraphite2.so.3 Those libraries are from the following packages: graphite2-1.2.4 gtk2-2.24.25_1 harfbuzz-0.9.36 pango-1.36.8 I have deleted these, rebuilt them using gcc 4.8, and now I'm waiting for a full rebuild of openoffice itself. When that completes, I'll let you know whether the segfault has gone away. I certainly hope so... :-)
Found another culprit: Catchpoint 1 Inferior loaded /usr/local/openoffice-4.1.1/openoffice4/program/../program/libspell.uno.so /usr/local/lib/libhunspell-1.3.so.0 /usr/lib/libc++.so.1 /lib/libcxxrt.so.1 E.g. this one has to be rebuilt using gcc 4.8+ too.
And another one: Inferior loaded /usr/local/openoffice-4.1.1/openoffice4/program/../program/liblnth.uno.so /usr/local/lib/libmythes-1.2.so.0 /usr/lib/libc++.so.1 /lib/libcxxrt.so.1 This one comes from textproc/mythes. After rebuilding this one with gcc 4.8+ too, the Save As dialog comes up without a crash. I tried some light testing, such as navigating through several menus and dialogs, trying the different OOo apps, and some other things, but I did not see any other crashes. So for now, the list of packages that *must* be built with gcc48+'s copy of libstdc++ is this: graphics/graphite2 x11-toolkits/gtk20 print/harfbuzz textproc/hunspell textproc/mythes x11-toolkits/pango Of course, it would be nicest if openoffice could build with clang, but if that is very hard to get right, there is also an alternative solution: using the devel/libc++ and devel/libcxxrt ports. Baptiste has implemented this for several other ports that *had* to build with gcc/g++, but still needed a newer C++ library. This approach ensures that different C++ standard libraries are not mixed with each other. Note that it would be nice to have some sort of mechanism where you can easily detect at runtime that you are mixing libstdc++/libsupc++ and libc++/libcxxrt. I would even suggest a fatal error or abort() in such a case...
Great catch! libgraphite2 must be getting brought in by one of the other libraries that libvclplug_gtk is linked against because openoffice is configured to use it's own private copy of graphite. Before I made that change the build failed because one of the intermediate build tools pulled in the system libgraphite and croaked because of the libstdc++ vs. libc++ conflict. Looking at the build log, libvclplug_gtk is linked against libgtk-x11-2.0, libgdk-x11-2.0, libpangocairo-1.0, libcairo, libpangoft2-1.0, and libpango-1.0, plus a bunch of other stuff. The configure script has a knob to switch to an internal version of cairo. It looks like there might be a way of using an internal version of pango, though there's not a command line switch for it. It's also possible to disable gtk.
Building with an internal copy of hunspell is also possible.
And building with an internal version of mythes is also possible.
Do you have any pointers to ports that have been converted to devel/libc++ and devel/libcxxrt? I started work on compiling with clang, see review D1693.
One problem I ran into when building with clang appears to be a bug in clang 3.4. I had to use 3.5 in order to build the port. Unfortunately, FreeBSD 10 is stuck with 3.4, so I have to somehow force the use of 3.5 from ports.
(In reply to Don Lewis from comment #22) You could have a look at the Makefile changes done in https://svnweb.freebsd.org/ports?view=revision&revision=342622 for rawtherapee. Specifically, this part: # ------------------------------------------------------------------- # USE_GCC must be late so the compiler feature checks work to detect # that the base C++ standard library switched to libc++: # We also must pin 4.8+ because 4.6 and 4.7 segfault on 10.0-RELEASE amd64 # wwhen compiling improcfun.cc: USE_GCC= yes .if ${COMPILER_FEATURES:Mlibc++} LDFLAGS+= -L/usr/local/lib/c++ CXXFLAGS+= -nostdinc++ -isystem /usr/local/include/c++/v1 CFLAGS+= -isystem /usr/local/include/c++/v1 BUILD_DEPENDS+= ${LOCALBASE}/lib/c++/libstdc++.so:${PORTSDIR}/devel/libc++ .endif
After thinking about this for a bit, I don't think that sticking with gcc and switching to libc++ is all that helpful The most complicated part of switching to clang is the code changes needed for libc++ exception handling. Also, we can't just globally switch to libc++ because the libraries that you found that are dragging in libc++ will drag in libstdc++ on FreeBSD 8 and 9. It looks like we are best off sticking with gcc from ports when the base compiler is gcc, and compiling with clang >= 3.5 if the base compiler is clang. Then we have to detect whether we are using libstdc++ or libc++ and then chose the proper flavor of the exception handling code.
(In reply to Don Lewis from comment #23) Don, what was the bug you encountered with clang 3.4.1?
(In reply to Dimitry Andric from comment #26) When building libdbase.so, I get this error: ./usr/bin/ld: .../../../unxfbsdx.pro/slo/DTable.o: relocation R_X86_64_PC32 against `_ZThn192_N12connectivity4file10OFileTable7acquireEv' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value The problem is that the symbol in question is trying to use 32-bit relocation on amd64, which apparently is not permitted. % objdump -r DTable.o | grep 'FileTable.*acquire' 000000000000c4a8 R_X86_64_PC32 _ZThn192_N12connectivity4file10OFileTable7acquireEv+0xfffffffffffffffc 000000000000eb2c R_X86_64_PLT32 _ZN12connectivity4file10OFileTable7acquireEv+0xfffffffffffffffc 000000000000f5b7 R_X86_64_PLT32 _ZN12connectivity4file10OFileTable7acquireEv+0xfffffffffffffffc 0000000000000018 R_X86_64_64 _ZN12connectivity4file10OFileTable7acquireEv 0000000000000160 R_X86_64_64 _ZThn8_N12connectivity4file10OFileTable7acquireEv 0000000000000190 R_X86_64_64 _ZThn16_N12connectivity4file10OFileTable7acquireEv 00000000000001c0 R_X86_64_64 _ZThn24_N12connectivity4file10OFileTable7acquireEv 00000000000001f0 R_X86_64_64 _ZThn32_N12connectivity4file10OFileTable7acquireEv 0000000000000228 R_X86_64_64 _ZThn48_N12connectivity4file10OFileTable7acquireEv 0000000000000298 R_X86_64_64 _ZThn80_N12connectivity4file10OFileTable7acquireEv 00000000000002d8 R_X86_64_64 _ZThn120_N12connectivity4file10OFileTable7acquireEv 0000000000000310 R_X86_64_64 _ZThn128_N12connectivity4file10OFileTable7acquireEv 0000000000000340 R_X86_64_64 _ZThn136_N12connectivity4file10OFileTable7acquireEv 0000000000000370 R_X86_64_64 _ZThn144_N12connectivity4file10OFileTable7acquireEv 00000000000003a8 R_X86_64_64 _ZThn152_N12connectivity4file10OFileTable7acquireEv 0000000000000428 R_X86_64_64 _ZThn176_N12connectivity4file10OFileTable7acquireEv 0000000000000510 R_X86_64_64 _ZThn184_N12connectivity4file10OFileTable7acquireEv 0000000000000548 R_X86_64_64 _ZThn192_N12connectivity4file10OFileTable7acquireEv 00000000000005a8 R_X86_64_64 _ZThn304_N12connectivity4file10OFileTable7acquireEv The symbol is undefined in the the mentioned .o file and is defined in another shared library that libdbase.so is being linked against. The problem is that the symbol in question is trying to use 32-bit relocation on amd64, which apparently is not permitted because there is no guarantee that the runtime linker will place the libraries nearby, especially if ASLR is in use. I haven't tried building on i386, since I haven't yet implemented the i386 version of the exception handling code. I did verify that clang 3.5 works and only 3.4.1 is broken. Even if I put the effort into generating a test case to get the bug in 3.4.1 fixed, that still doesn't help that much because we need to build packages for 10.1-RELEASE, which would still have the broken compiler.
I was able to entirely disable libvclplug_gtk.so, which gets rid of one consumer of gtk and pango, as well as harfbuzz and graphite. I configured the port to build private copies of hunspell. The result worked better and I was able to do most things that caused it to crash, but it was still not stable. I found also found that the CoinMP and redland ports brought in libc++. I tried to build private copies of those as well, but I got a build error on redland. I think the build code for that has rotted. I think I've wasted too much time on this approach. It doesn't help that the build time almost doubles in this configuration. My priority at this point is to get the clang build working.
A commit references this bug: Author: truckman Date: Tue Mar 17 15:04:53 UTC 2015 New revision: 381494 URL: https://svnweb.freebsd.org/changeset/ports/381494 Log: Unbreak editors/openoffice-4 and editors/openoffice-devel on systems where clang is the base compiler. The issue was that these ports would only successfully build with gcc and libstdc++, so they specified USE_GCC=yes, but they linked to other C++ ports that were compiled with clang, which brought in libc++. The conflict between libstdc++ and libc++ caused the application to crash whenever an operation that popped up a dialog box was attempted. Thanks to dim@ for helping me track this down. The fix is to patch various bits of the openoffice souce to allow it to be built with clang on systems where the C++ dependencies are also compiled with clang. [1] Add a CUPS option so that CUPS can be disabled [2]. Register print/cups-client as a LIB_DEPENDS when CUPS is enabled. pkg-message claims that user settings are stored in ~/.openoffice,org4, whereas all other platforms seem to use ~/.openoffice.org/4 (or equivalent), and both openoffice-4 and openoffice-devel actually use ~/.openoffice.org-devel/4. The addition of -devel to the location happened with r325370. The / appears to have been introduced in r297259. Change the location match other platforms. Introduce a new variable ${AOOUDIR} so that the actual location and pkg-message stay in sync. Rename ${OOOTAG} to ${AOOTAG} and restore its value so that it can once again be substituted into pkg-message. It has not been set since r296269. Various Makefile cleanups: * Gather and sort USE_* * Simplify use of ${REINPLACE_CMD} * --x-includes and --x-libraries are automatically passed to configure, which ignores them * Get rid of unnecessary include of bsd.port.options.mk PR: 188088 [1] PR: 198458 [2] Differential Revision: https://reviews.freebsd.org/D2055 Reviewed by: pfg Approved by: mat (mentor) Changes: head/editors/openoffice-4/Makefile head/editors/openoffice-4/files/patch-bridges_source_cpp__uno_gcc3__freebsd__intel_except.cxx head/editors/openoffice-4/files/patch-bridges_source_cpp__uno_gcc3__freebsd__intel_share.hxx head/editors/openoffice-4/files/patch-bridges_source_cpp__uno_gcc3__freebsd__intel_uno2cpp.cxx head/editors/openoffice-4/files/patch-bridges_source_cpp__uno_gcc3__freebsd__x86-64_except.cxx head/editors/openoffice-4/files/patch-bridges_source_cpp__uno_gcc3__freebsd__x86-64_share.hxx head/editors/openoffice-4/files/patch-bridges_source_cpp__uno_gcc3__freebsd__x86-64_uno2cpp.cxx head/editors/openoffice-4/files/patch-freebsd.mk head/editors/openoffice-4/files/patch-shell_source_unix_sysshell_recently__used__file__handler.cxx head/editors/openoffice-4/files/patch-unxfbsd.mk head/editors/openoffice-4/files/pkg-message.in head/editors/openoffice-devel/Makefile head/editors/openoffice-devel/files/patch-bridges_source_cpp__uno_gcc3__freebsd__intel_except.cxx head/editors/openoffice-devel/files/patch-bridges_source_cpp__uno_gcc3__freebsd__intel_share.hxx head/editors/openoffice-devel/files/patch-bridges_source_cpp__uno_gcc3__freebsd__intel_uno2cpp.cxx head/editors/openoffice-devel/files/patch-bridges_source_cpp__uno_gcc3__freebsd__x86-64_except.cxx head/editors/openoffice-devel/files/patch-bridges_source_cpp__uno_gcc3__freebsd__x86-64_share.hxx head/editors/openoffice-devel/files/patch-bridges_source_cpp__uno_gcc3__freebsd__x86-64_uno2cpp.cxx head/editors/openoffice-devel/files/patch-freebsd.mk head/editors/openoffice-devel/files/patch-shell_source_unix_sysshell_recently__used__file__handler.cxx head/editors/openoffice-devel/files/patch-unxfbsd.mk head/editors/openoffice-devel/files/pkg-message.in
I am able to confirm the crash is fixed, thanks!
A big thank you for this fix! Confirmed on FreeBSD 10.1-STABLE amd64. I am checking: has this fix been reported upstream?
(In reply to Sean Farley from comment #31) Yes, the plan is for the patches that allow building with clang on FreeBSD to be pushed upstream after a bit more polishing. Also, the build failure reported by the ports building cluster on FreeBSD 11 i386 also needs to be investigated. Unfortunately I don't have a machine running FreeBSD 11 at the moment.