Bug 61155 - When compiled with the base compiler (gcc-4.2.1) soffice.bin segfaults at startup
Summary: When compiled with the base compiler (gcc-4.2.1) soffice.bin segfaults at sta...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.6.5.2 release
Hardware: x86-64 (AMD64) FreeBSD
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-20 06:16 UTC by Mikhail T.
Modified: 2015-04-25 06:49 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail T. 2013-02-20 06:16:27 UTC
configure-script is run with the following arguments:
--with-unix-wrapper="libreoffice"  --disable-fetch-external  --with-build-version="FreeBSD ports 3.6.5_2"  --with-vendor="FreeBSD ports 3.6.5_2"  --exec-prefix=/opt  --with-gnu-patch=/opt/bin/gpatch  --with-external-tar=/usr/ports/distfiles/libreoffice  --with-num-cpus=`/sbin/sysctl -n kern.smp.cpus`  --with-solver-and-workdir-root=/home/tmp/lobuild  --with-system-boost  --with-system-clucene  --with-system-mdds  --with-system-lcms2  --with-system-libcdr  --with-system-libxml  --with-system-cairo  --enable-cairo-canvas  --with-system-zlib  --with-system-icu  --with-system-db  --with-system-jpeg  --with-system-expat  --with-system-openssl  --with-system-curl  --with-system-libvisio  --with-system-libwpd  --with-system-libwpg  --with-system-libwps  --with-system-poppler  --with-system-redland  --with-system-hunspell  --with-system-mythes  --with-system-altlinuxhyph  --with-system-libexttextcat  --with-system-lpsolve  --with-system-vigra  --with-alloc=system  --with-system-stdlibs  --with-system-mesa-headers  --disable-epm  --disable-mozilla  --disable-build-mozilla  --without-system-mozilla  --without-fonts  --without-afms  --without-stlport  --disable-kde  --disable-kdeab  --with-system-nss  --without-myspell-dicts  --with-system-dicts  --disable-dependency-tracking  --with-external-thes-dir=/opt/share/mythes  --with-external-hyph-dir=/opt/share/hyphen  --with-external-dict-dir=/opt/share/hunspell  --disable-zenity  --enable-graphite  --with-system-graphite  --enable-gio  --disable-nsplugin  --disable-linkoo  --disable-online-update  --with-system-gettext  --with-system-libpng  --disable-gnome-vfs  --enable-python=system --enable-ext-pdfimport --enable-cups --without-ppds --enable-postgresql-sdbc --with-system-postgresql --disable-systray --enable-gstreamer --enable-librsvg=system --enable-gtk --disable-gtk3 --enable-neon --with-system-neon --disable-kde4 --enable-gconf --without-java --disable-mergelibs --disable-odk --enable-release-build --with-qt-includes=/opt/include/qt4  --with-qt-libraries=/opt/lib/qt4  --with-extra-libs=/opt/lib  --with-extra-includes=/opt/include --with-system-cppunit                 --x-libraries=/opt/lib --x-includes=/opt/include --prefix=/opt

The build and install both succeed, but the application refuses to come up -- only the splash-screen appears. After the attempt, the core-file -- dumped by the soffice.bin process -- can be found in the working directory.

According to the debugger:
(gdb) bt full
#0  0x00000008021af9cc in com::sun::star::uno::Type::getTypeClass (this=0x0)
    at Type.h:147
No locals.
#1  0x00000008021ae5d4 in __getTypeEntries (cd=0x801ed5240)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/implbase_ex.cxx:108
        pEntry = (cppu::type_entry *) 0x801ed5268
        rType = (const com::sun::star::uno::Type &) @0x0: Error accessing memory address 0x0: Bad address.
(gdb) where
#0  0x00000008021af9cc in com::sun::star::uno::Type::getTypeClass (this=0x0)
    at Type.h:147
#1  0x00000008021ae5d4 in __getTypeEntries (cd=0x801ed5240)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/implbase_ex.cxx:108
#2  0x00000008021af271 in __queryDeepNoXInterface (pDemandedTDR=0x80d4a1880, 
    cd=0x801ed5240, that=0x80e3ff8c0)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/implbase_ex.cxx:186
#3  0x00000008021af7b6 in cppu::WeakImplHelper_query (rType=@0x80d43bdb8, 
    cd=0x801ed5240, that=0x80e3ff8c0, pBase=0x80e3ff8c0)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/implbase_ex.cxx:344
#4  0x0000000811b5bbdc in cppu::WeakImplHelper1<com::sun::star::lang::XEventListener>::queryInterface (this=0x80e3ff8c0, rType=@0x80d43bdb8)
    at implbase1.hxx:115
#5  0x000000080215b573 in com::sun::star::uno::BaseReference::iquery (
    pInterface=0x80e3ff8e8, rType=@0x80d43bdb8) at Reference.hxx:52
#6  0x00000008021b40e8 in com::sun::star::uno::Reference<com::sun::star::lang::XEventListener>::iquery (pInterface=0x80e3ff8e8) at Reference.hxx:67
#7  0x00000008021b410f in Reference (this=0x7fffffffc8a0, 
    pInterface=0x80e3ff8e8) at Reference.hxx:163
#8  0x00000008021b188a in cppu::OInterfaceContainerHelper::disposeAndClear (
    this=0x80d7eede0, rEvt=@0x7fffffffc9b0)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/interfacecontainer.cxx:323
#9  0x00000008021b1c0d in cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear (this=0x80d4a4648, rEvt=@0x7fffffffc9b0)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/interfacecontainer.cxx:500
#10 0x00000008021713e2 in cppu::OComponentHelper::dispose (this=0x80d4a4600)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/component.cxx:185
#11 0x00000008021a6132 in cppu::OFactoryComponentHelper::dispose (
    this=0x80d4a4600)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/factory.cxx:516
#12 0x0000000811b4de43 in stoc_smgr::OServiceManager::disposing (
    this=0x80d7e7fc0)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/stoc/source/servicemanager/servicemanager.cxx:923
#13 0x00000008021ac9cd in cppu::WeakComponentImplHelperBase::dispose (
    this=0x80d7e7fc0)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/implbase.cxx:277
#14 0x0000000811b5e25d in cppu::WeakComponentImplHelper7<com::sun::star::lang::X
MultiServiceFactory, com::sun::star::lang::XMultiComponentFactory, com::sun::star::lang::XServiceInfo, com::sun::star::lang::XInitialization, com::sun::star::container::XSet, com::sun::star::container::XContentEnumerationAccess, com::sun::star::beans::XPropertySet>::dispose (this=0x80d7e7fc0) at compbase7.hxx:78
#15 0x0000000811b49911 in stoc_smgr::OServiceManager::dispose (
    this=0x80d7e7fc0)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/stoc/source/servicemanager/servicemanager.cxx:904
#16 0x0000000811b4994d in stoc_smgr::ORegistryServiceManager::dispose (
    this=0x80d7e7fc0)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/stoc/source/servicemanager/servicemanager.cxx:1619
#17 0x00000008021ad34e in cppu::WeakComponentImplHelperBase::release (
    this=0x80d7e7fc0)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/implbase.cxx:248
#18 0x0000000811b5e2f3 in cppu::WeakComponentImplHelper7<com::sun::star::lang::XMultiServiceFactory, com::sun::star::lang::XMultiComponentFactory, com::sun::star::lang::XServiceInfo, com::sun::star::lang::XInitialization, com::sun::star::container::XSet, com::sun::star::container::XContentEnumerationAccess, com::sun::star::beans::XPropertySet>::release (this=0x80d7e7fc0) at compbase7.hxx:76
#19 0x000000080215ac4a in ~Reference (this=0x7fffffffcf50) at Reference.hxx:117
#20 0x000000080218ab2a in createTypeRegistry (uris=@0x7fffffffd110, 
    libraryDirectoryUri=@0x7fffffffd0f0)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/defaultbootstrap.cxx:2184
#21 0x000000080218bc66 in cppu::defaultBootstrap_InitialComponentContext (
    iniUri=@0x7fffffffd160)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/defaultbootstrap.cxx:2203
#22 0x000000080218be06 in cppu::defaultBootstrap_InitialComponentContext ()
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/cppuhelper/source/defaultbootstrap.cxx:2210
#23 0x0000000800b0d04d in desktop::Desktop::InitApplicationServiceManager ()
    at stl_function.h:225
#24 0x0000000800afab15 in desktop::Desktop::Init ()
   from /opt/lib/libreoffice/program/libsofficeapp.so
#25 0x000000080567153e in InitVCL () at string.hxx:312
#26 0x000000080567189b in ImplSVMain () at string.hxx:312
#27 0x0000000805671a05 in SVMain () at string.hxx:312
#28 0x0000000800b2c349 in soffice_main ()
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/desktop/source/app/sofficemain.cxx:83
#29 0x00000000004007a3 in sal_main ()
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/desktop/source/app/main.c:34
#30 0x0000000000400788 in main (argc=1, argv=0x7fffffffd540)
    at /home/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/desktop/source/app/main.c:33

So, rType is NULL, but is referenced anyway leading to the crash. The pEntry, more specifically is:
(gdb) p *pEntry
$14 = {m_type = {
    getCppuType = 0x801b51418 <com::sun::star::lang::XTypeProvider::static_type(void*)>, typeRef = 0x801b51418}, m_offset = 32}
(gdb) p *pEntry->m_type.typeRef
$15 = {nRefCount = -443987883, nStaticRefCount = 283935560, 
  eTypeClass = 4168976712, pTypeName = 0xc3c9ffffffd6e800, 
  pType = 0x20ec8348e5894855, pUniqueIdentifier = 0x8244488fe45b60f, 
  pReserved = 0xe8240488ff45b60f}

Please, advise... Thanks!
Comment 1 Stephan Bergmann 2013-02-20 10:00:32 UTC
This is already using UNO type information while bootstrapping the type information database (frame 20, createTypeRegistry).  Either something is horribly broken and leads to this code path that should normally not be taken; building with --enable-debug and/or --enable-dbgutil (requires a complete rebuild, --enable-dbgutil swiches the output dirs from solenv/*.pro to solenv/* etc.) should reveal that.  Or, this should pick up the "comprehensively" generated UNO type information in workdir/*/UnoApiHeadersTarget/udkapi/comprehensive/com/sun/star/.../*.hpp files (which is specificially there to use UNO type information already during bootstrap) but for some reason doesn't.

The latter would typically be due to symbol visibility problems, where one library that shall use a "comprehensive" cppu_detail_getCppuType variant erroneously binds against a "normal" one from another library.  <http://cgit.freedesktop.org/libreoffice/core/commit/?id=dee53a32a9feba2021782db5762b5a9a034efae4> "Temporary hack around cppu_detail_getCppuType variants violating ODR" should mitigate that problem, but maybe doesn't for you.  Depending on linker, LD_DEBUG might help to find out whether libraries like libuno_cppuhelper link to symbols with "cppu_detail_getCppuType" in their names that come from other libraries.
Comment 2 Mikhail T. 2013-02-20 15:03:02 UTC
Thanks for the analysis, Stephen. Is there anything I can do in practice to help you further?

I built without any -O flags and with -g, but without asking configure for any debugging explicitly.

ld.so on FreeBSD does not have LD_DEBUG. There is something else, though, which allows to dump the information for each symbol after the shared libraries are loaded. I ran that output through c++filt: http://aldan.algebra.com/~mi/port-stuff/soffice-ld-objects.txt (17Mb!).

Yes, it is likely, that some work-around is attempted, but fails. Normally, FreeBSD port editors/libreoffice builds the suit with either clang or gcc46 (or newer), which works for most people. But gcc-4.2.1 is the base compiler and I'd like to be able to build with that... What else can I do to help debug this?
Comment 3 Stephan Bergmann 2013-02-20 15:36:05 UTC
(In reply to comment #2)
> Yes, it is likely, that some work-around is attempted, but fails. Normally,
> FreeBSD port editors/libreoffice builds the suit with either clang or gcc46
> (or newer), which works for most people. But gcc-4.2.1 is the base compiler
> and I'd like to be able to build with that... What else can I do to help
> debug this?

I'm sorry, but at least I don't have any real bandwidth to help you there.
Comment 4 bfoman (inactive) 2014-03-08 22:35:53 UTC
LO 3.6.x and 4.0.x branches are in the End Of Life state so please recheck with latest stable version of LibreOffice and update this report as the build code received many changes.
Comment 5 kengraebe 2014-03-10 16:42:43 UTC
this may be related to my 75926 which to me is critical.
Comment 6 Karen LibreOpenOff 2014-09-24 17:03:52 UTC
please help me update my LibreOpenOffice product.  each time i try to download and open the update, i get a notice from apple that the image is not recognized.  i am running my mac on the most current mavericks (OS 10X) operating system.  i download the update and then the default to update LOO is to put it onto the DiscMounter.  the default "save" is NOT how the mac or else your update is to be applied to my system.  PLEASE HELP ME!  i get notices constantly that tell me an update is available, even while working on my documents.  today i wished to take a new fax coversheet template, but all i saw was the image of the new one, with a black "x" at the top left side of the small image of it.  PLEASE HELP on that too.  sincerely, karen dallas hartig
Comment 7 Mikhail T. 2014-09-24 17:20:43 UTC
(In reply to comment #6)
> please help me update my LibreOpenOffice product. [...] PLEASE HELP ME!

Congratulations to the entire LibreOffice crew. Your software has riched the coveted "For Dummies" level of popularity.
Comment 8 bfoman (inactive) 2014-09-24 17:36:21 UTC
(In reply to comment #6)
> please help me update my LibreOpenOffice product.  

Please do not (ab)use others' issues as support requests and do not use QA contact field for things not QA related. 
If you have a problem with your download always verify the checksums.
Comment 9 Alex Thurgood 2015-01-03 17:40:56 UTC
Adding self to CC if not already on
Comment 10 Julien Nabet 2015-04-19 12:06:21 UTC
Mikhail: any update with recent LO version? Indeed a lot of cleaning has been done on code since 2 years.
(just a pointer that you may already know: https://wiki.documentfoundation.org/Development/BuildingOnLinux)
Comment 11 Mikhail T. 2015-04-24 23:13:46 UTC
Sorry, I've upgrade all of my computers to FreeBSD-10.x since then and my base system compiler is now clang.
Comment 12 Julien Nabet 2015-04-25 06:49:27 UTC
Thank you for your feedback.
So let's put this one to WFM.
If someone reproduces this, please don't hesitate to reopen this tracker.