| Summary: | testtool.bin crashes | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Petr Mladek <pmladek> |
| Component: | LibreOffice | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | ||
| Priority: | medium | ||
| Version: | 3.4.0 Beta3 | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 35673 | ||
| Attachments: | backtrace without debug info :-( | ||
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. |
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 ---