Fedora's (registry.fedoraproject.org) LibreOffice flatpak crashing after latest update

Ask Fedora
, ,
1

This happened after the latest LibreOffice flatpak update. So sometime yesterday for me.

I haven’t seen anyone post about this yet, not even on Reddit or GitHub (last I checked), so I’m starting to wonder if anyone else even uses the flatpak from registry.fedoraproject.org? I use it since it’s what pops up for me by default in GNOME Software (and I tend to opt for Fedora-sourced flatpaks with all other apps as well).

Issue:
I run Silverblue on seven different machines. A variety of Lenovo, Dell, and HP laptops, two Lenovo m93p Thincentres, and one custom built gaming desktop. No NVIDIA anywhere, all Wayland. Only layered packages are steam-devices and simple-scan.

● fedora:fedora/36/x86_64/silverblue
                  Version: 36.20220728.0 (2022-07-28T00:44:48Z)
               BaseCommit: 71c9f4b42bf3d6d7e1206bc2ff2e778821a4fec768452963f3a070668dcacb2b
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
          LayeredPackages: simple-scan steam-devices

Some LibreOffice apps open and crash after trying to do something in the menu. Namely, LibreOffice Calc.

Some crash on open, like LibreOffice Writer.

I ran the application in safe mode, reset to factory settings. No effect.

I deleted the .var config folder for LibreOffice. No effect.

I reinstalled the flatpak itself. No effect.

Installed the flathub version of LibreOffice and noticed no issues whatsoever.

Here’s my terminal output from trying to open Fedora’s flatpak of LibreOffice Writer:

javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
terminate called recursively


Fatal exception: Signal 6
Stack:
/app/lib64/libreoffice/program/libuno_sal.so.3(+0x39522)[0x7fd71c459522]
/app/lib64/libreoffice/program/libuno_sal.so.3(+0x3970a)[0x7fd71c45970a]
/lib64/libc.so.6(+0x3ea70)[0x7fd71c175a70]
/lib64/libc.so.6(+0x8ec4c)[0x7fd71c1c5c4c]
/lib64/libc.so.6(raise+0x16)[0x7fd71c1759c6]
/lib64/libc.so.6(abort+0xcf)[0x7fd71c15f7f4]
/lib64/libstdc++.so.6(+0xb04ca)[0x7fd71bf994ca]
/lib64/libstdc++.so.6(+0xae43c)[0x7fd71bf9743c]
/lib64/libstdc++.so.6(+0xad4a9)[0x7fd71bf964a9]
/lib64/libstdc++.so.6(__gxx_personality_v0+0x86)[0x7fd71bf96bc6]
/lib64/libgcc_s.so.1(+0x16c74)[0x7fd71bdffc74]
/lib64/libgcc_s.so.1(_Unwind_Resume+0x12d)[0x7fd71be006cd]
/app/lib64/libreoffice/program/libvcllo.so(+0x319eaf)[0x7fd718b7feaf]
/app/lib64/libreoffice/program/libuno_sal.so.3(+0x3964a)[0x7fd71c45964a]
/lib64/libc.so.6(+0x3ea70)[0x7fd71c175a70]
/lib64/libc.so.6(+0x8ec4c)[0x7fd71c1c5c4c]
/lib64/libc.so.6(raise+0x16)[0x7fd71c1759c6]
/lib64/libc.so.6(abort+0xcf)[0x7fd71c15f7f4]
/lib64/libstdc++.so.6(+0xa2b57)[0x7fd71bf8bb57]
/lib64/libstdc++.so.6(+0xae43c)[0x7fd71bf9743c]
/lib64/libstdc++.so.6(+0xae4a7)[0x7fd71bf974a7]
/lib64/libstdc++.so.6(+0xae708)[0x7fd71bf97708]
/app/lib64/libreoffice/program/../program/libpyuno.so(+0xa157)[0x7fd6fd3a8157]
/app/lib64/libreoffice/program/../program/libpyuno.so(+0xa15c)[0x7fd6fd3a815c]
/app/lib64/libreoffice/program/../program/libpyuno.so(_ZNK5pyuno7Runtime19extractUnoExceptionERKNS_5PyRefES3_S3_+0x599)[0x7fd6fd3b7259]
/app/lib64/libreoffice/program/../program/libpythonloaderlo.so(pyuno_Loader_get_implementation+0x1bc)[0x7fd70409056c]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x615b2)[0x7fd71b8145b2]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x6177e)[0x7fd71b81477e]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x61814)[0x7fd71b814814]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x6363d)[0x7fd71b81663d]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x64040)[0x7fd71b817040]
/app/lib64/libreoffice/program/liblnglo.so(+0x5ccc0)[0x7fd7161d2cc0]
/app/lib64/libreoffice/program/liblnglo.so(+0x5e81f)[0x7fd7161d481f]
/app/lib64/libreoffice/program/liblnglo.so(+0x6256e)[0x7fd7161d856e]
/app/lib64/libreoffice/program/liblnglo.so(+0x57b80)[0x7fd7161cdb80]
/app/lib64/libreoffice/program/liblnglo.so(linguistic_LngSvcMgr_get_implementation+0x3b3)[0x7fd7161d4133]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x615b2)[0x7fd71b8145b2]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x6177e)[0x7fd71b81477e]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x61814)[0x7fd71b814814]
/app/lib64/libreoffice/program/../program/libswlo.so(_ZN8SwModuleC2EP16SfxObjectFactoryS1_S1_+0x564)[0x7fd6e62ef0b4]
/app/lib64/libreoffice/program/../program/libswlo.so(+0xe08656)[0x7fd6e6573656]
/app/lib64/libreoffice/program/../program/libswlo.so(_ZN9SwGlobals6ensureEv+0x35)[0x7fd6e62ddbc5]
/app/lib64/libreoffice/program/../program/libswlo.so(Writer_SwTextDocument_get_implementation+0x3c)[0x7fd6e64a8c3c]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x615b2)[0x7fd71b8145b2]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x61728)[0x7fd71b814728]
/app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x61814)[0x7fd71b814814]
/app/lib64/libreoffice/program/libsfxlo.so(+0x3d838e)[0x7fd71ae5038e]
/app/lib64/libreoffice/program/libfwklo.so(+0x180832)[0x7fd71b34f832]
/app/lib64/libreoffice/program/libfwklo.so(+0xf1ab2)[0x7fd71b2c0ab2]
/app/lib64/libreoffice/program/libfwklo.so(+0xf1fc1)[0x7fd71b2c0fc1]
/app/lib64/libreoffice/program/libsfxlo.so(+0x249f0f)[0x7fd71acc1f0f]
/app/lib64/libreoffice/program/libvcllo.so(+0x427358)[0x7fd718c8d358]
/app/lib64/libreoffice/program/libvcllo.so(_ZN16SalUserEventList18DispatchUserEventsEb+0x199)[0x7fd718eed8e9]
/app/lib64/libreoffice/program/libvclplug_gtk3lo.so(+0xf04bd)[0x7fd705fcc4bd]
/lib64/libglib-2.0.so.0(+0x514cb)[0x7fd7153c34cb]
/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x19f)[0x7fd7153c6faf]
/lib64/libglib-2.0.so.0(+0xaa2c8)[0x7fd71541c2c8]
/lib64/libglib-2.0.so.0(g_main_context_iteration+0x30)[0x7fd7153c4940]
/app/lib64/libreoffice/program/libvclplug_gtk3lo.so(+0xf35fb)[0x7fd705fcf5fb]
/app/lib64/libreoffice/program/libvcllo.so(+0x6c9212)[0x7fd718f2f212]
/app/lib64/libreoffice/program/libvcllo.so(_ZN11Application7ExecuteEv+0x45)[0x7fd718f357f5]
/app/lib64/libreoffice/program/libsofficeapp.so(+0x3eacb)[0x7fd71c380acb]
/app/lib64/libreoffice/program/libvcllo.so(_Z10ImplSVMainv+0x36a)[0x7fd718f4047a]
/app/lib64/libreoffice/program/libsofficeapp.so(soffice_main+0x183)[0x7fd71c3973d3]
/app/lib64/libreoffice/program/soffice.bin(+0x10bf)[0x55e17d1a40bf]
/lib64/libc.so.6(+0x29550)[0x7fd71c160550]
/lib64/libc.so.6(__libc_start_main+0x89)[0x7fd71c160609]
/app/lib64/libreoffice/program/soffice.bin(+0x10f5)[0x55e17d1a40f5]

On the GUI side of things, when I try to open LibreOffice Writer using the menu icon, I get this:

27f0413ecb2ee148d4a551f55dd0edbec2398e92.png

Besides uninstalling this and using the flatpak from flathub, any help would be appreciated! Thank you!

1 Like
2

Hello @benkei-kuruma ,
Welcome to ask.:fedora:project.org!
Yes I can confirm there appears to be an uncaught exception in the LibreOffice flatpak. Though I do not have any java runtime errors.

3 Likes
3

Hrm, if this is the Flatpak from the Fedora registry, I expect one should file a bug to inform the maintainers. You can use the “file a bug report” link here to file one:

2 Likes
4

Thank you both! I’ll report the bug.

And just for the record, I’m migrating all of my flatpaks to flathub. Easier to manage them that way.

If anyone is Googling and wants a simple way to migrate from fedora remote to flathub, here’s what I did:

flatpak install $(flatpak list --app --columns=application) --reinstall

When asked, choose “flathub” remote, or otherwise choose “yes” for a flathub flatpak it wants you to install as a dependency.

After it’s done, remove the fedora remote from your system with:

flatpak remote-delete fedora

When prompted, remove the fedora platform runtimes, which should be the only thing remaining on your system from the fedora remote.

Just for good measure, run this last:

flatpak remove --unused

5

you can also specify the remote in the install command with flatpak install [OPTION…] [LOCATION/REMOTE] [REF…] so in the case of flathub flatpak install flathub [application ref]

This bug still seems to exist in Fedora’s flatpak.

6

Indeed, I see some movement at my bug report, but I’ve since removed the Fedora remote and use flathub exclusively, as noted above. This is honestly quite a long time for a showstopping bug to persist in such a standard use case piece of software like a word processor, something many rely on for school or work. Then again, I wager no one really uses the Fedora remote version anyway.

7

Well in response to …

It works fine from the Fedora official repo when installed via DNF.

Why not? Fedora flatpaks receive the same review process and QA as any package in the official Fedora repo, so they are better than the flathub (I don’t know for sure where this came from) version in that respect.

1 Like
8

Flatpaks from any source are inherently not kept as up to date as the rpm versions. This is due to delays in receiving the latest software, building the flatpak, testing, distribution, etc.

The nature of flatpaks are that they should work for the version they were tested on and all later versions, but changes in the underlying OS (including the kernel) may interfere.

If at all possible users should use the rpm versions and only use flatpaks for the outlier reasons (such as on silverblue, kinoite, or other systems that are immutable, or other cases where the rpm is not available).

9

Yeah word, I mean theoretically, there shouldn’t be a difference between rpm and fedora remote flatpaks, right? Maybe the rpm is broken as well. Or not, since I haven’t seen anyone post about it either.

That no one else has posted about this crashing bug anywhere else on the web (to my knowledge) kinda implies no one else is using the Fedora remote for this flatpak, or there is something wrong with Silverblue. I wouldn’t know either way. I have seen others post about other issues with Fedora remote flatpaks, though.

I half expected to see this under “common issues” but didn’t. So I made this account to post about the bug after troubleshooting, searching, and waiting a few days for a patch. :sweat_smile:

Or it could be that Fedora flatpak users just don’t use libre office? :thinking: Again, I wouldn’t know. I’m just some dude. :wink:

10

Definitely not, as I stated it works fine as installed on Fedora Workstation from the official Fedora Linux repo.

Or it could mean only a few are getting hit with it. I don’t see the correlation to “something is wrong with Silverblue” though.

1 Like
11

Yeah, I dunno man. :man_shrugging:t5: Silverblue is really the only constant among all the computers I have tried this flatpak on. Just common sense deduction here, where if it ain’t the flatpak remote itself, it must be the immutable OS.

I’m rather tired of this pointless back-and-forth at this point, though. All I’m saying is, I’m willing to be a lot more people are using the flathub version (i.e., not just Fedora users), hence more eyeballs, bug reports, and attention. If the flathub version of libre office was broken for a whole week, I’m willing to bet someone would have said something by now. But I could be wrong. I don’t really follow these things as much as you might.

Not really sure what else there is to say, but it probably doesn’t matter in the grand scheme of things since apparently no one else is affected.

I got it working with flathub so I’m good. Hope the bug gets fixed for others regardless.

Peace.