Re: core dumped while bulding on illumos XStreamOS

On 16.02.2015 12:09, Gabriele Bulfon wrote:
> Thanks Michael,
>
> I got this, on gdb.
> Take into account: default python is 2.6, installed also 2.7 and 3.3,
> config.log shows python3 is taken.
>
> (gdb) run
> Starting program:
> /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/bin/uno.bin
> -s com.sun.star.test.bridge.BridgeTest --
> com.sun.star.test.bridge.CppTestObject
> -env:LO_BUILD_LIB_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Library
> -env:URE_MORE_SERVICES=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/Rdb/uno_services.rdb
> -env:URE_MORE_TYPES=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/UnoApiTarget/bridgetest.rdb
> [Thread debugging using libthread_db enabled]
> [New Thread 1 (LWP 1)]
> Traceback (most recent call last):
> File
> "/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/lib/libuno_sal.so.3-gdb.py",
> line 12, in <module>
> import importlib
> ImportError: No module named importlib
> [New LWP 2 ]
> Traceback (most recent call last):
> File
> "/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/lib/libuno_cppu.so.3-gdb.py",
> line 12, in <module>
> import importlib
> ImportError: No module named importlib

those messages come from gdb itself - we have some Python files that are
loaded into gdb and allow you to pretty-print LO data types like the
UTF-16 strings.  the Python version used for that is determined by gdb
and has *nothing* to do with the python used for LO; not sure why it
doesn't work for you (are you sure your gdb has the python feature
enabled?).

> terminate called after throwing an instance of
> 'com::sun::star::uno::RuntimeException'

the problem with C++ exceptions is that at the time std::terminate is
invoked, the information why the exception was thrown is gone already.

you need to set a breakpoint with "catch throw" on where the exception
is raised; the last hit of that breakpoint before the crash is the
problematic one.