Bug 36802 - testtool.bin crashes
Summary: testtool.bin crashes
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
3.4.0 Beta3
Hardware: All Linux (All)
: medium critical
Assignee: Not Assigned
Depends on:
Blocks: mab3.4
  Show dependency treegraph
Reported: 2011-05-03 07:28 UTC by Petr Mladek
Modified: 2011-05-10 01:51 UTC (History)
0 users

See Also:
Crash report or crash signature:

backtrace without debug info :-( (25.09 KB, text/x-log)
2011-05-03 07:28 UTC, Petr Mladek

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Mladek 2011-05-03 07:28:25 UTC
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 ---
Comment 1 Petr Mladek 2011-05-03 07:30:07 UTC
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.
Comment 2 Michael Meeks 2011-05-03 13:52:33 UTC
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
Comment 3 Michael Meeks 2011-05-09 13:36:39 UTC
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.
Comment 4 Michael Meeks 2011-05-09 13:50:09 UTC
pushed a fix to master, and patch for review to the list.
Comment 5 Michael Meeks 2011-05-10 01:51:57 UTC
so fixed.