> I'm trying to launch LO 7.4.7 on a Q4OS GNU/Linux distribution, on an i386 platform (Intel Atom N270); with limited memory (1GB).

That's a really old LO version, in a very "limited" environment.

Do you have any chance to try a current LO version there?

Does it work with SAL_USE_VCLPLUGIN=gen?

(In reply to Michael Weghorn from comment #1)
> > I'm trying to launch LO 7.4.7 on a Q4OS GNU/Linux distribution, on an i386 platform (Intel Atom N270); with limited memory (1GB).
> 
> That's a really old LO version, in a very "limited" environment.

It's quite a new LO version, released a little over 2 years ago. I don't believe there are any "really old" LO versions, at all...

The environment is, indeed, limited. I believe Q4OS renews their packages once every 3 years or so.

> 
> Do you have any chance to try a current LO version there?

That machine will probably not handle building LO, I'm afraid. Can I get some 32-bit Linux builds from somewhere?

> Does it work with SAL_USE_VCLPLUGIN=gen?

So, in this case, I only get as far as the "terminate called" - but the process hangs and doesn't return. Process tree:

bash---oosplash-+-soffice.bin---{soffice.bin}
                \-{oosplash}

(In reply to Eyal Rozenberg from comment #2)
> It's quite a new LO version, released a little over 2 years ago. I don't
> believe there are any "really old" LO versions, at all...

OK, "really old" may be relative, but the version has been out of (upstream) support for more than a year by now.

> That machine will probably not handle building LO, I'm afraid. Can I get
> some 32-bit Linux builds from somewhere?

I don't know Q4OS myself, but according to their website, it's Debian-based and [1] suggests that the current version is based on Debian 12 (bookworm), so you might try installing LO 24.8 from the Debian backports repository: [2]
(You can either replace the Q4OS-provided packages or just unpack similar to the TDF daily builds [3]. Maybe setting LD_LIBRARY_PATH to the directory containing the libs when starting LO could be needed in case of the latter.)

Building e.g. in a 32-bit chroot of the distro on a 64-bit system could be another option, but requires some more effort.

(In reply to Eyal Rozenberg from comment #0)
> I get the following:
> ```
> Warning: failed to launch javaldx - java may not function correctly

If not installed yet, installing a JRE/JDK might fix this warning, e.g. package openjdk-17-jdk in Debian bookworm. (Or just the runtime, i.e. openjdk-17-jre should be enough, I guess.)

> (soffice:14008): dbind-WARNING **: 16:53:58.636: AT-SPI: Error retrieving
> access
> ibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.a11
> y.Bus was not provided by any .service files

On Debian, package at-spi2-core would provide the corresponding file: /usr/share/dbus-1/services/org.a11y.Bus.service

From looking at the backtrace, I'm not sure whether the above 2 warnings are really related to the actual crash, though. But it's always good to rule out other problems that may or may not be related.


[1] https://q4os.org/blog.html
[2] https://packages.debian.org/search?suite=bookworm-backports&searchon=names&keywords=libreoffice
[3] https://wiki.documentfoundation.org/Installing_in_parallel/Linux

(In reply to Michael Weghorn from comment #3)
> OK, "really old" may be relative, but the version has been out of (upstream)
> support for more than a year by now.

Understood, but unless this is a known issue, then whatever the problem is might affect newer versions as well, so it's still worthwhile to try and figure this out.


> I don't know Q4OS myself, but according to their website, it's Debian-based
> and [1] suggests that the current version is based on Debian 12 (bookworm),
> so you might try installing LO 24.8 from the Debian backports repository:

I'll try that first and report.

> Building e.g. in a 32-bit chroot of the distro on a 64-bit system could be
> another option, but requires some more effort.


> If not installed yet, installing a JRE/JDK might fix this warning, e.g.
> package openjdk-17-jdk in Debian bookworm. (Or just the runtime, i.e.
> openjdk-17-jre should be enough, I guess.)
> 
> > (soffice:14008): dbind-WARNING **: 16:53:58.636: AT-SPI: Error retrieving
> > access
> > ibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name
> > org.a11
> > y.Bus was not provided by any .service files
> 
> On Debian, package at-spi2-core would provide the corresponding file:
> /usr/share/dbus-1/services/org.a11y.Bus.service

I installed these two. The dbind-WARNING is gone; the message about failing to launch javaldx - remains.

It's weird, though: How come the Debian packages don't have those two packages as dependencies, on one hand - but the libreoffice executables try and fail to use them, on the other hand? i.e. rely at least partially on them being available?

> From looking at the backtrace, I'm not sure whether the above 2 warnings are
> really related to the actual crash, though. But it's always good to rule out
> other problems that may or may not be related.

So, we've removed those potential causes, but the conundrum remains. Will try using the 32-bit Debian packages.

Ok, update:

* I added the bookworm-backports apt repository
* I installed the LO packages with version 24.8.2-1~bpo12+1
* No more weird stack trace, but:
* Now getting just:

Warning: failed to launch javaldx - java may not function correctly
terminate called after throwing an instance of 'com::sun::star::uno::RuntimeExce
ption'

... and it crashes.

(In reply to Eyal Rozenberg from comment #4)
> Understood, but unless this is a known issue, then whatever the problem is
> might affect newer versions as well, so it's still worthwhile to try and
> figure this out.

Sure, but ideally using current versions (which you're doing now) to avoid spending too many resources on issues that might already be fixed and we can't fix for old versions that no longer get updates anyway (unless distros backport fixes, but such issues are not something tracked here, but rather in the distro issue trackers).

> I installed these two. The dbind-WARNING is gone; the message about failing
> to launch javaldx - remains.

To be sure: Do you have libreoffice-java-common installed as well?

> It's weird, though: How come the Debian packages don't have those two
> packages as dependencies, on one hand - but the libreoffice executables try
> and fail to use them, on the other hand? i.e. rely at least partially on
> them being available?

Technically, you can use LibreOffice (lacking some features then) without Java. For instance, if I force to LO to use a non-existent Java using

    UNO_JAVA_JFW_JREHOME=file:///tmp/something/invalid libreoffice --writer

, I also get a "javaldx failed!" warning, but LibreOffice starts just fine otherwise. I'd expect that Debian uses a "Recommends" on some Java version somewhere in the LO package dependency chain rather than a hard "Depends". (Recommended packages are still installed by default, but it's possible to not have them installed.) It's a bit like not hard-depending on libreoffice-gtk3 or libreoffice-kf5: You can use LibreOffice without these (or just the particular one you're interested in), but if none of them is installed, you'll get the "gen" VCL plugin...

In any case, that's a decision of the distro packagers.

(In reply to Eyal Rozenberg from comment #5)
> Warning: failed to launch javaldx - java may not function correctly
> terminate called after throwing an instance of
> 'com::sun::star::uno::RuntimeExce
> ption'
> 
> ... and it crashes.

Does starting with `libreoffice --backtrace` give anything useful, or maybe alternatively `coredumpctl dump` if coredumpctl is in use?

Installing the corresponding -dbgsym packages will help getting a more useful backtrace, e.g.:

* The backtrace in the initial description shows `/usr/lib/libreoffice/program/libxmlreaderlo.so`
* `dpkg -S /usr/lib/libreoffice/program/libxmlreaderlo.so` tells that this file is provided by package `uno-libs-private`
* The debug symbols are then provided by a package called `uno-libs-private-dbgsym`

(In reply to Michael Weghorn from comment #7)
> To be sure: Do you have libreoffice-java-common installed as well?

Actually no, it wasn't. And when I do install it and its dependencies - the message about javaldx disappears, but the exception remains: com::su::star::uno::RuntimeException . So, changing the title. But I will open another bug about that error message - which should not be emitted IMHO.

> Does starting with `libreoffice --backtrace` give anything useful, or maybe
> alternatively `coredumpctl dump` if coredumpctl is in use?

Will attach the gdbtrace.log.


> Installing the corresponding -dbgsym packages will help getting a more
> useful backtrace, e.g.:

I could not locate any -dbgsym packages , even though I had the bookmworm-backports repository enabled :-(

But - the new trace log shows:

/usr/lib/libreoffice/program/libcomphelper.so

and no libxmlreaderlo.so

Created attachment 197109 [details]
gdbtrace.log from a crashing run with --backtrace

(In reply to Eyal Rozenberg from comment #8)
> I could not locate any -dbgsym packages , even though I had the
> bookmworm-backports repository enabled :-(

dbgsym packages happen to be in a separate repo. Can you try adding

    deb https://deb.debian.org/debian-debug/ bookworm-backports-debug main

to your /etc/apt/sources.list (or some /etc/apt/sources.list.d/${whatever}.list) and try again please?

(The current backtrace shows comphelper::detail::ConfigurationWrapper::get at least somewhere further up in the trace, but knowing where exactly that fails could help.)

Created attachment 197113 [details]
gdbtrace.log from a crashing run with --backtrace

Installed libreoffice-core-dbgsym and re-generated the GDB trace.

The relevant part seems to be:

#9  0xb74670da in com::sun::star::configuration::ReadWriteAccess::create () at ./workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/configuration/ReadWriteAccess.hpp:50
#10 0xb7464281 in comphelper::detail::ConfigurationWrapper::ConfigurationWrapper () at ./comphelper/source/misc/configuration.cxx:114
#11 0xb746432d in comphelper::detail::ConfigurationWrapper::get () at ./comphelper/source/misc/configuration.cxx:107
#12 0xb7dd2b2f in comphelper::ConfigurationProperty<officecfg::Setup::Office::OfficeRestartInProgress, bool>::get () at ./include/comphelper/configuration.hxx:223

and the snippet of configuration.cxx is:

comphelper::detail::ConfigurationWrapper::ConfigurationWrapper(
    css::uno::Reference<css::uno::XComponentContext> const & context):
    context_(context.is() ? context : comphelper::getProcessComponentContext()),
    access_(css::configuration::ReadWriteAccess::create(context_, u"*"_ustr))
{}

(In reply to Eyal Rozenberg from comment #11)
> Created attachment 197113 [details]
> gdbtrace.log from a crashing run with --backtrace
> 
> Installed libreoffice-core-dbgsym and re-generated the GDB trace.
> 
> The relevant part seems to be:
> 
> #9  0xb74670da in com::sun::star::configuration::ReadWriteAccess::create ()
> at
> ./workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/configuration/
> ReadWriteAccess.hpp:50
> #10 0xb7464281 in
> comphelper::detail::ConfigurationWrapper::ConfigurationWrapper () at
> ./comphelper/source/misc/configuration.cxx:114
> #11 0xb746432d in comphelper::detail::ConfigurationWrapper::get () at
> ./comphelper/source/misc/configuration.cxx:107
> #12 0xb7dd2b2f in
> comphelper::ConfigurationProperty<officecfg::Setup::Office::
> OfficeRestartInProgress, bool>::get () at
> ./include/comphelper/configuration.hxx:223
> 
> and the snippet of configuration.cxx is:
> 
> comphelper::detail::ConfigurationWrapper::ConfigurationWrapper(
>     css::uno::Reference<css::uno::XComponentContext> const & context):
>     context_(context.is() ? context :
> comphelper::getProcessComponentContext()),
>     access_(css::configuration::ReadWriteAccess::create(context_, u"*"_ustr))
> {}

That's not code I'm very familiar with. From looking a bit into the code, something might go (have gone) wrong somewhere when creating the component context/services.

Some questions:

1) Does this also happen with a new user profile, or in safe mode?
2) Is package `libreoffice` installed? (which *should* take care of installing relevant other packages and avoid having an "interesting" combination of just single packages)
3) Do you have a `/usr/lib/libreoffice/program/unorc` that looks something like this:

[Bootstrap]
URE_INTERNAL_LIB_DIR=${ORIGIN}
URE_INTERNAL_JAVA_DIR=${ORIGIN}/classes
URE_INTERNAL_JAVA_CLASSPATH=${URE_MORE_JAVA_TYPES}
UNO_TYPES=${ORIGIN}/types.rdb ${URE_MORE_TYPES}
UNO_SERVICES=${ORIGIN}/services.rdb ${URE_MORE_SERVICES}

4) Are there any environment variables set in your setup that might mess with the installation in some way? (Does `env` output contain anything that looks like it might be related, e.g. some variable starting with `UNO_` or `URE_`?
5) Is this a fresh installation of Q4OS? If not: Did LO ever work there in the past?
6) Any other ideas?

7) `dpkg -l | grep -E '(libreoffice)|(uno)'` output might also be helpful

(In reply to Michael Weghorn from comment #13)
> 1) Does this also happen with a new user profile, or in safe mode?

It is a new user profile - it's the first time LO is run on this machine. Safe mode - same thing.

> 2) Is package `libreoffice` installed? (which *should* take care of
> installing relevant other packages and avoid having an "interesting"
> combination of just single packages)

Yes, it is.


> 3) Do you have a `/usr/lib/libreoffice/program/unorc` that looks something
> like this:

Yes, exactly as you listed it.

> 4) Are there any environment variables set in your setup that might mess
> with the installation in some way? (Does `env` output contain anything that
> looks like it might be related, e.g. some variable starting with `UNO_` or
> `URE_`?

None of the last two kinds. There are some XDM_ and XDG_ variables, and also GTK_RC_FILES and QT_QPA_PLATFORMTHEME.

> 5) Is this a fresh installation of Q4OS?

Yes, except for the backported LO 24.8.2

> 6) Any other ideas?

Well, even libreoffice --help fails!  so, something very early.

I would say that there needs to be some "robustification" of the configuration/configuration-wrapper related code. There must some places assuming that configuration options/settings can be obtained, when they cannot.

Also, app.cxx line 485 is:

  if (officecfg::Setup::Office::OfficeRestartInProgress::get())

I don't know if the first start is considered a restart; or whether there's some failure in starting LO which triggers a restart. But - I would look at the code checking for "restart in progress" - maybe that's where we'll find some invalid assumptions on what's available.

Anyway, I'm going to switch distributions on that machine now, so it is unfortunately going away.

Could this possibly be due to a low monitor resolution? i.e. below our minimum requirements?

(In reply to Eyal Rozenberg from comment #15)
> I would say that there needs to be some "robustification" of the
> configuration/configuration-wrapper related code. There must some places
> assuming that configuration options/settings can be obtained, when they
> cannot.

Making code more robust is of course always a good idea. The bigger challenge is probably to decide what to spend the (limited) resources (here in particular developer time) on.

> Also, app.cxx line 485 is:
> 
>   if (officecfg::Setup::Office::OfficeRestartInProgress::get())
> 
> I don't know if the first start is considered a restart; or whether there's
> some failure in starting LO which triggers a restart. But - I would look at
> the code checking for "restart in progress" - maybe that's where we'll find
> some invalid assumptions on what's available.

Looking into Desktop::Init, I see a call to `InitApplicationServiceManager` a few lines above the ones you mention. As I said, I'm not very familiar with that area of LO code, but my "gut feeling" is that something might go wrong there, and then the call to `officecfg::Setup::Office::OfficeRestartInProgress::get` failing is just a consequence of that.

> Anyway, I'm going to switch distributions on that machine now, so it is
> unfortunately going away.

What might be most useful to get more insights could be to debug + compare what happens in the broken case and a working setup. If the broken setup is going away altogether, that probably makes this less actionable.


(In reply to Eyal Rozenberg from comment #17)
> Could this possibly be due to a low monitor resolution? i.e. below our
> minimum requirements?

I won't say "No", but from the backtrace, I tend to think that this is more likely a more low-level issue.

(In reply to Michael Weghorn from comment #18)
> Making code more robust is of course always a good idea. The bigger
> challenge is probably to decide what to spend the (limited) resources (here
> in particular developer time) on.

Fair enough. But I would say it's worthwhile to invest in preventing crashes. Too bad I wasn't able to focus us more.


> Looking into Desktop::Init, I see a call to `InitApplicationServiceManager`
> a few lines above the ones you mention. As I said, I'm not very familiar
> with that area of LO code, but my "gut feeling" is that something might go
> wrong there, and then the call to
> `officecfg::Setup::Office::OfficeRestartInProgress::get` failing is just a
> consequence of that.

Well, I guess we'll leave it at that for now.

> What might be most useful to get more insights could be to debug + compare
> what happens in the broken case and a working setup. If the broken setup is
> going away altogether, that probably makes this less actionable.

The broken setup was:

1. Install Q4OS 5.5r1 32-bit 
2. Use the "Profiler" utility to install the "full" distribution
2. Try to run LibreOffice from a comand-line

that's it. Although maybe I should mention the hardware: LG X130 sub-notebook computer:
https://gadgetaz.com/Netbook/LG_X130--3140

(In reply to Eyal Rozenberg from comment #19)
> Fair enough. But I would say it's worthwhile to invest in preventing
> crashes.

Definitely.

On the other hand, "Eyal can't use LO on one of his devices" seemed a bit more pressing/motivating than "There was a crash in a pretty much non-standard setup, and we don't really know what the underlying problem was and can't really reproduce/analyze/test this any more at the moment."
(Even trying to create an environment where it would maybe be possible to reproduce this again would require some extra effort.)