https://bugs.documentfoundation.org/show_bug.cgi?id=173425
Bug ID: 173425
Summary: unopkg add crashes with unhandled std::bad_alloc
instead of a proper error when the user's extension
deployment registry contains stale references to files
that no longer exist
Product: LibreOffice
Version: 24.2.7.2 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Extensions
Assignee: [email protected]
Reporter: [email protected]
Created attachment 208383
--> https://bugs.documentfoundation.org/attachment.cgi?id=208383&action=edit
The ini file
LibreOffice version: 24.2.7.2 420(Build:2) (Ubuntu package
4:24.2.7-0ubuntu0.24.04.6)
OS: Ubuntu 24.04, Linux 6.14 (x86_64)
Steps to reproduce:
1. Have a LibreOffice user profile in which at least one previously
installed user extension was removed by deleting its files/temp
directories directly (or where a previous `unopkg add`/`remove`
was interrupted -- e.g. by a session logout, a crash, or a kill
-9), so that references to it survive in the deployment registry
under
~/.config/libreoffice/4/user/uno_packages/cache/registry/
even though the files they point to are gone. In our case this
was visible in (at least) two places:
-
.../com.sun.star.comp.deployment.configuration.PackageRegistryBackend/configmgr.ini
(its DATA= line listed 8 paths under a long-deleted extension's
extraction directory)
-
.../com.sun.star.comp.deployment.script.PackageRegistryBackend/backenddb.xml
(listed a <script:script> entry pointing at the same
long-deleted extraction directory, plus another entry pointing
at an earlier, already-cleaned-up extraction directory of a
*different*, still-installed extension)
We also found a stale entry in
~/.config/libreoffice/4/user/uno_packages/cache/uno_packages.pmap
pointing at a temp extraction directory that had already been
removed.
2. Run `unopkg add --force <any-extension>.oxt` from a shell (no
running soffice instance required to reproduce -- we could
reproduce it with soffice not running at all).
Actual results:
unopkg fails every time with:
ERROR: Exception occurred: C++ code threw St9bad_alloc: std::bad_alloc
at ./bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:243
ERROR: unopkg failed.
This message is generic (it's the bridge's catch-all report for any
C++ exception crossing the UNO bridge) and gives no indication of
what actually went wrong. A gdb `catch throw` on unopkg.bin shows the
exception is thrown from libxmlreaderlo.so, called from
cppu::defaultBootstrap_InitialComponentContext() -- i.e. it happens
very early, while UNO itself is still bootstrapping and merging the
CONFIGURATION_LAYERS (per fundamentalrc), before unopkg even looks at
the extension being added:
#0 __cxa_throw () from libstdc++.so.6
#1 ?? () from libxmlreaderlo.so
#2 ?? () from libuno_cppuhelpergcc3.so.3
#3 ?? () from libuno_cppuhelpergcc3.so.3
#4 ?? () from libuno_cppuhelpergcc3.so.3
#5 cppu::defaultBootstrap_InitialComponentContext(rtl::OUString const&)
#6 cppu::defaultBootstrap_InitialComponentContext()
#7 ?? () from libunopkgapp.so
#8 unopkg_main () from libunopkgapp.so
(The distro package has no debug symbols and debuginfod.ubuntu.com was
unreachable from our network, so we could not resolve frames #1-4 to
exact source lines/functions. Sorry -- this is as far as we could
narrow it down without building from source.)
`unopkg list` does NOT crash under the same conditions and happily
prints the stale/dangling entries as "is registered: no" -- only
`unopkg add` hits the crash.
The fix that made it go away:
Removing the dangling entries from configmgr.ini's DATA= line, from
the script backend's backenddb.xml, and clearing the stale
uno_packages.pmap entry (each backed up first) let `unopkg add`
proceed past this point. We arrived at these three files by bisection
(temporarily moving registry/* subdirectories aside one at a time and
re-testing).
Caveat: our reproduction was not 100% deterministic across every
single one of our test runs after the partial fixes, which makes us
suspect that besides "the referenced file doesn't exist", there may
also be a code path where the referenced file *does* exist but is
zero-length (we also found several stray zero-byte
"<ExtensionName>.oxtproperties" files accumulated from repeated failed
install attempts, for more than one extension, though we're not
certain these are read at the point where the crash happens or are
just an unrelated side effect of the same aborted operations).
Expected results:
Either unopkg add should tolerate stale/dangling registry references
(same as `unopkg list` does), or it should fail with a clear,
specific error naming the offending file/entry -- not an unhandled
std::bad_alloc with a meaningless generic message.
Additional info:
This looks like a general robustness/error-handling gap in the
extension-manager bootstrap's configuration-layer merging when the
user profile's own bookkeeping (uno_packages/cache/registry/*,
uno_packages.pmap) has drifted out of sync with what's actually on
disk -- which can apparently happen after nothing more unusual than
an interrupted unopkg operation (e.g. the machine's session ending
mid-operation). We did not find an existing bug report matching this
exact symptom (searched for "bad_alloc", "PackageRegistryBackend",
"defaultBootstrap_InitialComponentContext" on this tracker), but
apologise if it turns out to be a duplicate.
We're attaching the exact (sanitised) contents of the three
files we found stale entries in, if that's useful.
--
You are receiving this mail because:
You are the assignee for the bug.
