[Libreoffice] LibO 3.5RC2: terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException'

[Petr Mladek]

Stephan Bergmann píše v Pá 03. 02. 2012 v 22:10 +0100:
> On 02/03/2012 06:43 PM, Stephan Bergmann wrote:
> > On 02/03/2012 04:46 PM, Dag Wieers wrote:
> >> [dag at moria ~]$ /opt/libreoffice3.5/program/python
> >> Python 2.6.1 (r261:67515, Feb 1 2012, 15:06:46)
> >> [GCC 4.2.4] on linux2
> >> Type "help", "copyright", "credits" or "license" for more information.
> >>>>> import uno
> >> terminate called after throwing an instance of
> >> 'com::sun::star::registry::InvalidRegistryException'
> >> Aborted (core dumped)
> >
> > I can reproduce this with
> > LibO_3.5.0rc2_Linux_x86-64_install-rpm_en-US.tar.gz from
> > <http://www.libreoffice.org/download/pre-releases/>. The problem is that
> > readRdbFile (cppuhelper/soruce/bootstrap.cxx) in
> > /opt/libreoffice3.5/ure/lib/libuno_cppuhelpergcc3.so.3 calls
> > SimpleRegistry::open (stoc/source/simpleregistry/simpleregistry.cxx) in
> > /opt/libreoffice3.5/ure/lib/bootstrap.uno.so (with
> > rURL="file:///etc/opt/ure/types.rdb"), which throws an instance of
> > css.registry.InvalidRegistryException (correctly so, as rURL does not
> > exist), but the code in libuno_cppuhelpergcc3.so.3 fails to catch that
> > exception with its
> >
> > catch (css::registry::InvalidRegistryException & e) {
> >
> > code block. Very suspicious, esp. given that both
> > libuno_cppuhelpergcc3.so.3 and bootstrap.uno.so export the _ZTI/_ZTS
> > symbols for InvalidRegistryException (and new GCC versions no longer
> > compare on the brittle RTTI pointers, but on string equality, anyway).
> >
> > I have currently no idea what's broken there.
> 
> The secret is that the LO installation sets available from 
> <http://www.libreoffice.org/download> are built with implicit 
> --without-system-stdlibs, so they bring along ure/lib/libgcc_s.so.1 and 
> ure/lib/libstdc++.so.6 (which the programs in the LO installation, like 
> program/soffice.bin and program/python.bin, pick up at runtime).
> 
> For reasons that still escape me, this causes exception-handling trouble 
> for LO 3.5 program/python (which happens to set LD_LIBRARY_PATH, maybe 
> that makes a difference), but apparently not for LO 3.5 program/soffice, 
> nor reportedly for LO 3.4 program/python (as reported by Dag).
> 
> Removing /opt/libreoffice3.5/ure/lib/libgcc_s.so.1 and 
> /opt/libreoffice3.5/ure/lib/libstdc++.so.6 made the problem go away for 
> me on Fedora 16 x86_64.

Stefan, thanks a lot for investigating it.

I still wonder why it worked with 3.4. Maybe, it was because the python
binaries were not in the same directory with stdlibs.

> Petr, the best approach might be to build the "official" Linux LO 
> installation sets with explicit --with-system-stdlibs, so that the 
> installation sets do not bring along their own libgcc_s.so.1 and 
> libstdc++.so.6.  If the installation sets are built on a sufficiently 
> old baseline system, it should be a pretty safe bet that each box on 
> which they are installed bring along sufficiently new versions of those 
> libs as part of the system.

Hmm, I am a bit scared to do such change at this stage. I am not sure if
the stdlibs are 100% backward compatible, it there are not disabled some
features on some crazy systems. Note that we already have 3.5.0-rc3
which is supposed to be final.

One possibility would be to try system stdlibs in daily builds. Ask
people for testing. If we do not get any complains, we could try this
with 3.5.1`bug fix release that should get release 4 weeks from now.

People could remove the libs in 3.5.0 as a workaround.

How does that sound? Maybe, we should discuss this on TSC.


Best Regards,
Petr