LibreOffice - ftbfs on ARM, during the installer step

looks like the openoffice.org build failure on armel in lucid-proposed

This is the regcomp invocation that segfaults (long filenames because of the build pathname is long) obtained by adding print statements in the perl script that invokes it.

/media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/bin/regcomp -register -r /tmp/ooopackaging/i_64171294148165/unxlngr.pro/LibreOffice//gid_Starregistry_Services_Rdb_servicesrdb/en-US_inprogress_1/services.rdb -c 'file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/librptxmllr.so;file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/sax.uno.so;file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/libsblr.so;file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/libsclr.so;file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/libscdlr.so;file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/libscfiltlr.so;file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/libscnlr.so;file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/libscriptframe.so;file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/libsdlr.so;file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/libsdbc2.so;file:///media/4746efa7-0ac6-416e-a4d7-c437b88bd66d/panda/libo/libreoffice-3.3.0~rc2/libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro/lib/libsdbtlr.so' -wop='vnd.sun.star.expand:$OOO_BASE_DIR/program/'

Minimal invocation that triggers the segfault.

$cd libreoffice-build/build/libreoffice-3.3.0.2/solver/330/unxlngr.pro
$bin/regcomp -register -r services.rdb -c 'lib/librptxmllr.so;lib/sax.uno.so;lib/libsblr.so;lib/libsclr.so'

On second run it is fine, only when services.rdb is to be created it segfaults after an otherwise good looking run (all passed components registered). Less that those 4 .so-s and it is not happening.

It is a bad memory access on cleaning up the caches (called from memory pool desctructors),

I'll keep debugging it.

The crash happens in the atexit() handlers in rtl_cache_deactivate() called by rtl_cache_destroy() called from ~FixedMemPool()

a fix was commited upstream to the 3.3 branch so will hopefully be available in Ubuntu as part of 3.3.1

This is the patch in case it needs backporting to Lucid or elsewhere where OO.o FTBFS on armel because the cause is likely the same.

http://cgit.freedesktop.org/libreoffice/calc/commit/?h=libreoffice-3-3&id=d4d6a678bf169eebee2fe4d71c8ec66de6898d6e