Created attachment 46285 [details] backtrace without debug info :-( The bundled testtool.bin does not start at all. --- cut --- $> /opt/libreoffice/basis-link/program/testtool.bin Neoprávněný přístup do paměti (SIGSEGV) (core dumped) --- cut ---
A fallback is to use the prebuilt binaries from http://qa.openoffice.org/ooQAReloaded/AutomationTeamsite/ooQA-TeamAutomationBin.html Anyway, we should get it working out of box.
Looks like a fairly typical missing types.rdb problem around misc. UNO operators requiring the type database (although everything was known at compile time: nice hey ? ;-). Digging into the automation/ code I couldn't see 'main' (strangely), but I guess we need to do the cppu:: bootstrap properly first - cf. the regression tests in sc/qa/unit/ (eg.) A fuller trace, showing the NULL pTypeDescr being de-referenced is: Program received signal SIGSEGV, Segmentation fault. 0xb7103729 in cppu::_copyConstructAnyFromData (pDestAny=0xb55f26f0, pSource=0xbfffc42c, pType=0xb55f15a8, pTypeDescr=0x0, acquire= 0xb7dee299 <com::sun::star::uno::cpp_acquire(void*)>, mapping=0x0) at /data/opt/libreoffice/libreoffice-3-4/clone/ure/cppu/source/uno/copy.hxx:275 275 pDestAny->pData = ::rtl_allocateMemory( pTypeDescr->nSize ); (gdb) bt #0 0xb7103729 in cppu::_copyConstructAnyFromData (pDestAny=0xb55f26f0, pSource=0xbfffc42c, pType=0xb55f15a8, pTypeDescr=0x0, acquire= 0xb7dee299 <com::sun::star::uno::cpp_acquire(void*)>, mapping=0x0) at /data/opt/libreoffice/libreoffice-3-4/clone/ure/cppu/source/uno/copy.hxx:275 #1 0xb7103c9a in cppu::_copyConstructAny (pDestAny=0xb55f26f0, pSource=0xbfffc42c, pType=0xb55f15a8, pTypeDescr=0x0, acquire= 0xb7dee299 <com::sun::star::uno::cpp_acquire(void*)>, mapping=0x0) at /data/opt/libreoffice/libreoffice-3-4/clone/ure/cppu/source/uno/copy.hxx:386 #2 0xb710ac0e in uno_type_any_assign (pDest=0xb55f26f0, pSource=0xbfffc42c, pType=0xb55f15a8, acquire=0xb7dee299 <com::sun::star::uno::cpp_acquire(void*)>, release= 0xb7dee2ad <com::sun::star::uno::cpp_release(void*)>) at /data/opt/libreoffice/libreoffice-3-4/clone/ure/cppu/source/uno/any.cxx:50 #3 0xb7e104f2 in void com::sun::star::uno::operator<<=<com::sun::star::beans::PropertyValue>(com::sun::star::uno::Any&, com::sun::star::beans::PropertyValue const&) () from /data/opt/TTInstall/basis3.4/program/libutlli.so #4 0xb7e0eda3 in utl::ConfigManager::AcquireTree(utl::ConfigItem&) () from /data/opt/TTInstall/basis3.4/program/libutlli.so #5 0xb7e102d0 in utl::ConfigManager::AddConfigItem(utl::ConfigItem&) () from /data/opt/TTInstall/basis3.4/program/libutlli.so
The strace seems to show some crazy path usage too: access("/data/opt/OOInstall/basis3.4/program/../none/program/bootstraprc", F_OK) = ENOENT where does such a 'none' come from :-) most odd; creating a link in basis3.4 of none to '..' at least gives us a different, crash - later on (it seems). So really looks like some bad bootstrapping brokenness; related to configmgr's love of types.rdb to handle UNO name/property pairs in anys.
pushed a fix to master, and patch for review to the list.
so fixed.