Description of problem: 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. Version-Release number of selected component (if applicable): 7.3 How reproducible: Always happens. Steps to Reproduce: 1. Open LibreOffice apps. See description above. Actual results: Application crashes. Expected results: Application doesn't crash. Additional info: See my full post here: https://ask.fedoraproject.org/t/fedoras-registry-fedoraproject-org-libreoffice-flatpak-crashing-after-latest-update/24847
To reproduce, run `LC_ALL=cs_CZ.UTF-8 flatpak run org.libreoffice.LibreOffice --writer`, which happens to use some Python-based LibreOffice extension. It aborts due to "terminate called after throwing an instance of 'std::bad_alloc'" at > #6 0x00007ffff7ac74a7 in std::terminate() () at ~/.var/app/org.libreoffice.LibreOffice/cache/debuginfod_client/966126bdc5035b23b132a2a335b11a162f2f16fb/source##usr##src##debug##gcc-12.1.1-1.fc36.x86_64##obj-x86_64-redhat-linux##x86_64-redhat-linux##libstdc++-v3##libsupc++##..##..##..##..##libstdc++-v3##libsupc++##eh_terminate.cc:58 > #7 0x00007ffff7ac7708 in __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*)) (obj=<optimized out>, tinfo=0x7ffff7c3dd58 <typeinfo for std::bad_alloc>, dest=0x7ffff7ac5ae0 <std::bad_alloc::~bad_alloc()>) at ~/.var/app/org.libreoffice.LibreOffice/cache/debuginfod_client/966126bdc5035b23b132a2a335b11a162f2f16fb/source##usr##src##debug##gcc-12.1.1-1.fc36.x86_64##obj-x86_64-redhat-linux##x86_64-redhat-linux##libstdc++-v3##libsupc++##..##..##..##..##libstdc++-v3##libsupc++##eh_throw.cc:98 > #8 0x00007fffd9346157 in rtl::OString::OString(char16_t const*, int, unsigned short, unsigned int) [clone .part.0] [clone .lto_priv.0] (convertFlags=<optimized out>, encoding=<optimized out>, length=<optimized out>, value=<optimized out>, this=<optimized out>) at ~/.var/app/org.libreoffice.LibreOffice/cache/debuginfod_client/7e0e0eb6724d316075f3973066952e5e3dfe490e/source##usr##src##debug##libreoffice-7.3.4.2-4.module_f36+14678+33917bb8.x86_64##include##rtl##string.hxx:372 > #9 0x00007fffd934615c in pyuno::PyRef::PyRef(_object*, __sal_NoAcquire, pyuno::NotNull) (p=<optimized out>, this=<synthetic pointer>) at ~/.var/app/org.libreoffice.LibreOffice/cache/debuginfod_client/7e0e0eb6724d316075f3973066952e5e3dfe490e/source##usr##src##debug##libreoffice-7.3.4.2-4.module_f36+14678+33917bb8.x86_64##include##rtl##string.hxx:372 > #10 pyuno::importUnoModule() () at ~/.var/app/org.libreoffice.LibreOffice/cache/debuginfod_client/7e0e0eb6724d316075f3973066952e5e3dfe490e/source##usr##src##debug##libreoffice-7.3.4.2-4.module_f36+14678+33917bb8.x86_64##pyuno##source##module##pyuno_runtime.cxx:177 > #11 0x00007fffd9355259 in pyuno::RuntimeCargo::getUnoModule() (this=0x55555c7c5e40) at ~/.var/app/org.libreoffice.LibreOffice/cache/debuginfod_client/7e0e0eb6724d316075f3973066952e5e3dfe490e/source##usr##src##debug##libreoffice-7.3.4.2-4.module_f36+14678+33917bb8.x86_64##pyuno##source##module##pyuno_runtime.cxx:1006 > #12 pyuno::Runtime::extractUnoException(pyuno::PyRef const&, pyuno::PyRef const&, pyuno::PyRef const&) const (this=this@entry=0x7fffffffba48, excType=..., excValue=..., excTraceback=...) at ~/.var/app/org.libreoffice.LibreOffice/cache/debuginfod_client/7e0e0eb6724d316075f3973066952e5e3dfe490e/source##usr##src##debug##libreoffice-7.3.4.2-4.module_f36+14678+33917bb8.x86_64##pyuno##source##module##pyuno_runtime.cxx:867 > #13 0x00007fffd939456c in pyuno_loader::raiseRuntimeExceptionWhenNeeded () at ~/.var/app/org.libreoffice.LibreOffice/cache/debuginfod_client/a9a6c2259609d18fec3c1ba104de6ff1fd72de7b/source##usr##src##debug##libreoffice-7.3.4.2-4.module_f36+14678+33917bb8.x86_64##pyuno##source##loader##pyuno_loader.cxx:74 > #14 pyuno_loader::getLoaderModule () at ~/.var/app/org.libreoffice.LibreOffice/cache/debuginfod_client/a9a6c2259609d18fec3c1ba104de6ff1fd72de7b/source##usr##src##debug##libreoffice-7.3.4.2-4.module_f36+14678+33917bb8.x86_64##pyuno##source##loader##pyuno_loader.cxx:89 because the call to PyImport_ImportModule at > PyRef module( PyImport_ImportModule( "uno" ), SAL_NO_ACQUIRE, NOT_NULL ); in LibreOffice's importUnoModule code (at pyuno/source/module/pyuno_runtime.cxx:177) returned null. The reason is that the Python bundled in org.fedoraproject.Platform//f36 no longer searches for uno.py in /app/lib64/python3.10/site-packages: > $ flatpak run --runtime=org.fedoraproject.Platform//f36 --command=/usr/bin/python3 org.libreoffice.LibreOffice -m uno > /usr/bin/python3: No module named uno vs. > $ flatpak run --runtime=org.fedoraproject.Platform//f35 --command=/usr/bin/python3 org.libreoffice.LibreOffice -m uno > failed to load pyuno: '/lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /app/lib64/libreoffice/program/libpyuno.so)' (which apparently only fails after successfully finding the module, as the F36-based org.libreoffice.LibreOffice//stable requires the newer org.fedoraproject.Platform//f36 libstdc++).
This seems to be a fallout from https://bugzilla.redhat.com/show_bug.cgi?id=2026979 and the python path mangling that's done in https://src.fedoraproject.org/rpms/flatpak-runtime-config/blob/f36/f/usercustomize.py no longer works as expected. In F35 I get: $ python -c "import sysconfig; purelib = sysconfig.get_path('purelib', vars=dict(base='/app')); print(purelib)" /app/lib/python3.10/site-packages Whereas in F36 it's changed to /app/local: $ python -c "import sysconfig; purelib = sysconfig.get_path('purelib', vars=dict(base='/app')); print(purelib)" /app/local/lib/python3.10/site-packages
*** Bug 2115021 has been marked as a duplicate of this bug. ***
https://src.fedoraproject.org/rpms/flatpak-runtime-config/c/2a984132dcf6d65665a45a8ce4d17fcbfeb30615?branch=f36 should work this around for now.
FEDORA-FLATPAK-2022-6b2c20a9c6 has been submitted as an update to Fedora 36 Flatpaks. https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2022-6b2c20a9c6
FEDORA-FLATPAK-2022-6b2c20a9c6 has been pushed to the Fedora 36 Flatpaks stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Stephan Bergmann from comment #1) The crash and its root cause > > $ flatpak run --runtime=org.fedoraproject.Platform//f36 --command=/usr/bin/python3 org.libreoffice.LibreOffice -m uno > > /usr/bin/python3: No module named uno are back again with > $ flatpak info org.fedoraproject.Platform//f36 > > Fedora Platform - Shared libraries > > ID: org.fedoraproject.Platform > Ref: runtime/org.fedoraproject.Platform/x86_64/f36 > Arch: x86_64 > Branch: f36 > Version: 36 > License: GPL-2.0+ > Origin: fedora > Installation: system > Installed: 2.0 GB > > Commit: fd8bfba0786983de1530a83ddc579858a58bcd3c584ab4df39e977609bbbf92a > Subject: build of runtime/org.fedoraproject.Platform/x86_64/f36 > Date: 2022-09-07 20:10:58 +0000 > Alt-id: 227e551e5e06d38f81500422cb6da154f2265eaa7b72232f662043bb031ef1b3 presumably after <https://src.fedoraproject.org/rpms/flatpak-runtime-config/c/cfbfef479a3026558a6accdeb89f979d7341188a?branch=f36> "Revert 'Fix search paths for /app-installed python modules' (#2026979)"
Grr. Let me see if I can quickly fix this up.
OK, this should be fixed in new flatpak-runtime-f36-3620220907195736.2 build. The python update that fixes this, https://bodhi.fedoraproject.org/updates/FEDORA-2022-c072cdc3c8 is still in updates-testing so I had to create a buildroot override with the python packages to make sure that they get included in the flatpak runtime build. If the runtime update works for you, can you also +1 the python update above, please? I'll do the same. While the python in flatpak runtime now looks good in my testing, your uno loading command from above still does not work. Looks like all the python modules have gone missing from latest libreoffice flatpak build: $ flatpak run --runtime=org.fedoraproject.Platform//f36 --command=/usr/bin/ls org.libreoffice.LibreOffice /app/lib{,64}/python3.10/site-packages/ /usr/bin/ls: cannot access '/app/lib/python3.10/site-packages/': No such file or directory /usr/bin/ls: cannot access '/app/lib64/python3.10/site-packages/': No such file or directory Whereas if I downgrade to the previous one: $ flatpak run --runtime=org.fedoraproject.Platform//f36 --command=/usr/bin/ls org.libreoffice.LibreOffice /app/lib{,64}/python3.10/site-packages/ /app/lib64/python3.10/site-packages/: officehelper.py __pycache__ unohelper.py uno.py /app/lib/python3.10/site-packages/: libvoikko.py __pycache__
FEDORA-FLATPAK-2022-fbc5a73e3a has been submitted as an update to Fedora 36 Flatpaks. https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2022-fbc5a73e3a
(In reply to Kalev Lember from comment #9) > OK, this should be fixed in new flatpak-runtime-f36-3620220907195736.2 > build. The python update that fixes this, > https://bodhi.fedoraproject.org/updates/FEDORA-2022-c072cdc3c8 is still in > updates-testing so I had to create a buildroot override with the python > packages to make sure that they get included in the flatpak runtime build. Thanks, that fixes this issue fully for me. > While the python in flatpak runtime now looks good in my testing, your uno > loading command from above still does not work. Looks like all the python > modules have gone missing from latest libreoffice flatpak build: > > $ flatpak run --runtime=org.fedoraproject.Platform//f36 > --command=/usr/bin/ls org.libreoffice.LibreOffice > /app/lib{,64}/python3.10/site-packages/ > /usr/bin/ls: cannot access '/app/lib/python3.10/site-packages/': No such > file or directory > /usr/bin/ls: cannot access '/app/lib64/python3.10/site-packages/': No such > file or directory I cannot reproduce that with the latest > $ flatpak --system info org.libreoffice.LibreOffice > > LibreOffice - The LibreOffice productivity suite > > ID: org.libreoffice.LibreOffice > Ref: app/org.libreoffice.LibreOffice/x86_64/stable > Arch: x86_64 > Branch: stable > License: MPL-2.0 > Origin: fedora > Collection: > Installation: system > Installed: 2.8 GB > Runtime: org.fedoraproject.Platform/x86_64/f36 > Sdk: org.fedoraproject.Sdk/x86_64/f36 > > Commit: 2524765836b699583bb644af8153aaa33001bf54ac809becec1786a268ef77b7 > Subject: Export org.libreoffice.LibreOffice > Date: 2022-08-27 06:54:15 +0000 > Alt-id: 5900fc7b71d0122f94bc2db7e7a83dd0479d66b8c94592da6e179b8438601db9 (Did you accidentally try with a flathub LO flatpak instead?)
Excellent! Hah, that was flathub LO flatpak indeed :) Mystery solved!
FEDORA-FLATPAK-2022-fbc5a73e3a has been pushed to the Fedora 36 Flatpaks stable repository. If problem still persists, please make note of it in this bug report.
Still seeing this: [notting@nostromo: ~]$ flatpak info org.fedoraproject.Platform/x86_64/f36 Fedora Platform - Shared libraries ID: org.fedoraproject.Platform Ref: runtime/org.fedoraproject.Platform/x86_64/f36 Arch: x86_64 Branch: f36 Version: 36 License: GPL-2.0+ Origin: fedora Installation: system Installed: 2.0 GB Commit: 866fd9158078fe61247ca294a020c4457f5d5a8bfadd173aee5f02502d4e62f7 Subject: build of runtime/org.fedoraproject.Platform/x86_64/f36 Date: 2022-09-17 13:50:39 +0000 Alt-id: ce7efc2074f44faba1b7a9a08b2ce0ae586b39306577e1e86a3107d0879bb87e [notting@nostromo: ~]$ flatpak info org.fedoraproject.Platform/x86_64/f36 Fedora Platform - Shared libraries ID: org.fedoraproject.Platform Ref: runtime/org.fedoraproject.Platform/x86_64/f36 Arch: x86_64 Branch: f36 Version: 36 License: GPL-2.0+ Origin: fedora Installation: system Installed: 2.0 GB Commit: 866fd9158078fe61247ca294a020c4457f5d5a8bfadd173aee5f02502d4e62f7 Subject: build of runtime/org.fedoraproject.Platform/x86_64/f36 Date: 2022-09-17 13:50:39 +0000 Alt-id: ce7efc2074f44faba1b7a9a08b2ce0ae586b39306577e1e86a3107d0879bb87e [notting@nostromo: ~]$ libreoffice foo.ods terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Fatal exception: Signal 6 Stack: /app/lib64/libreoffice/program/libuno_sal.so.3(+0x39532)[0x7fc27b250532] /app/lib64/libreoffice/program/libuno_sal.so.3(+0x3971a)[0x7fc27b25071a] /lib64/libc.so.6(+0x3ea70)[0x7fc27ae3ea70] /lib64/libc.so.6(+0x8ec4c)[0x7fc27ae8ec4c] /lib64/libc.so.6(raise+0x16)[0x7fc27ae3e9c6] /lib64/libc.so.6(abort+0xcf)[0x7fc27ae287f4] /lib64/libstdc++.so.6(+0xa2b57)[0x7fc27aaa2b57] /lib64/libstdc++.so.6(+0xae3dc)[0x7fc27aaae3dc] /lib64/libstdc++.so.6(+0xae447)[0x7fc27aaae447] /lib64/libstdc++.so.6(+0xae6a8)[0x7fc27aaae6a8] /app/lib64/libreoffice/program/../program/libpyuno.so(+0xa157)[0x7fc23a911157] /app/lib64/libreoffice/program/../program/libpyuno.so(+0xa15c)[0x7fc23a91115c] /app/lib64/libreoffice/program/../program/libpyuno.so(_ZNK5pyuno7Runtime19extractUnoExceptionERKNS_5PyRefES3_S3_+0x599)[0x7fc23a920259] /app/lib64/libreoffice/program/../program/libpythonloaderlo.so(pyuno_Loader_get_implementation+0x1bc)[0x7fc24800a56c] /app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x615b2)[0x7fc27a6015b2] /app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x6177e)[0x7fc27a60177e] /app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x61814)[0x7fc27a601814] /app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x6363d)[0x7fc27a60363d] /app/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3(+0x64040)[0x7fc27a604040] ... [notting@nostromo: ~]$ flatpak run --runtime=org.fedoraproject.Platform//f36 --command=/usr/bin/python3 org.libreoffice.LibreOffice -m uno /usr/bin/python3: No module named uno
Grr... Sounds like we managed to break it one more time (the python3 update that fixed it spent a long time in updates-testing so it didn't get automatically included in stable flatpak runtime composes). But good news is that I just double checked and the latest flatpak runtime update, https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2022-7d5cf71e4b that's on it's way to stable updates has this fixed again, so it should sort itself out in a few hours hopefully.
Yes, works for me now. Thanks!
Great :)