Bug 253840 - editors/libreoffice: fails to start after update to 7.1.0.3_2 with "Application Error"
Summary: editors/libreoffice: fails to start after update to 7.1.0.3_2 with "Applicati...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: FreeBSD Office Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-25 09:21 UTC by Ruslan Makhmatkhanov
Modified: 2021-04-04 11:10 UTC (History)
8 users (show)

See Also:
bugzilla: maintainer-feedback? (office)


Attachments
output from libreoffice --backtrace (3.16 KB, text/plain)
2021-02-25 15:12 UTC, Bengt Ahlgren
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2021-02-25 09:21:29 UTC
After updating to package version 7.1.0.3_2 from official repo libreoffice fails to start with "Application Error". Splash screen appears after launching, then application exists. Here is the sample session:

> libreoffice 
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-rm'
Application Error

> /usr/local/lib/libreoffice/program/soffice --writer
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-rm'
Application Error

> libreoffice --writer
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-rm'
Application Error

It's on 14-current.
Comment 1 Li-Wen Hsu freebsd_committer freebsd_triage 2021-02-25 09:34:35 UTC
(In reply to Ruslan Makhmatkhanov from comment #0)
I suspect this is the same error with https://lists.freebsd.org/pipermail/freebsd-stable/2021-February/093200.html and the -CURRENT package builder has not caught up yet. Do you think you can try to build base system and port yourself?
Comment 2 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2021-02-25 09:42:37 UTC
Thanks for the info, will try.
Comment 3 Bengt Ahlgren 2021-02-25 10:52:51 UTC
(In reply to Ruslan Makhmatkhanov from comment #2)
Sounds like the same issue I ran into on 11.4-STABLE after the libcxxrt updates in the base system.  See recent conversation on the stable@ list.  Does the problem go away if you go back to an earlier base system version?
Comment 4 Bengt Ahlgren 2021-02-25 10:56:20 UTC
I should add that I have the same issue with several libreoffice versions, specifically 7.0.3.1_2 and 7.1.0.3_2, which I have not touched after the base system update.
Comment 5 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2021-02-25 11:34:08 UTC
I'll try to update base (it's already contains the fix) and see how it's going. Thanks.
Comment 6 Jakob Alvermark 2021-02-25 13:40:11 UTC
I got the same "Application Error" on -CURRENT when I updated from main-n244895-0a4f851074a to main-n244973-c02a28754bc.
I'm now on main-n245042-6f30ac9995f and still get this error.

I tried building it from ports, but I get the error described in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253738
Comment 7 Bengt Ahlgren 2021-02-25 15:12:24 UTC
Created attachment 222825 [details]
output from libreoffice --backtrace

Attaching output from libreoffice --backtrace

For current, does the problem go away if you go back to 	04d2d2d7fd22bba638ccb5a0b2e0805087a70cd3?

How can we determine if this is an issue with the changes to libcxxrt in the base system, or if that change exposed a latent bug in libreoffice?
Comment 8 Li-Wen Hsu freebsd_committer freebsd_triage 2021-02-25 15:45:14 UTC
(In reply to Bengt Ahlgren from comment #7)
Hope dim@ can help answer this. :-)
Comment 9 Dimitry Andric freebsd_committer freebsd_triage 2021-02-25 16:02:57 UTC
(In reply to Li-Wen Hsu from comment #8)
As I noted on the mailing list, libreoffice is just way too big to debug. This crash should be boiled down to a small self-contained test case. That is, if you can get it to crash then. :)

In any case, the changes in libcxxrt should not affect libreoffice, unless it is throwing exceptions using its own internal mechanism. (I seem to remember that it does some horrific things in general with APIs, but haven't looked at its exception handling.)

Does anybody know if libreoffice includes unwind.h anywhere, and makes use of the internals of struct _Unwind_Exception ?
Comment 10 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2021-02-25 20:07:53 UTC
So I just did that:

# cd /usr/src/lib/libcxxrt
# make && make install

now libreoffice works correctly

last commit in my /usr/src is:
commit 8f3c71c85e5f6a4d2bddbfead225d33b96dbd7d7 (HEAD -> main, origin/main, origin/HEAD)
Author: Emmanuel Vadot <manu@FreeBSD.org>
Date:   Thu Feb 25 18:10:19 2021 +0100
Comment 11 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2021-02-25 20:23:07 UTC
And since I did nothing with the libreoffice package itself (it's still the same 7.1.0.3_2 from official repo), it's obviously was libcxxrt problem, I think we can close this PR.
Comment 12 Nathan Whitehorn freebsd_committer freebsd_triage 2021-02-25 20:40:07 UTC
I can confirm that rebuilding libreoffice from source on a system patched with that change to libcxxrt results in working libreoffice. So I think just the package builders need to be updated.
Comment 13 Dimitry Andric freebsd_committer freebsd_triage 2021-02-25 20:55:26 UTC
Yeah, there was a window of a few days where libcxxrt was 'bad', and the package builders have picked that up. There is some logic in libreoffice's "UNO bridge" component that are interfacing directly with the declarations in unwind.h (don't look, it will permanently scar your eyeballs :), so it became incompatible.
Comment 14 Jakob Alvermark 2021-02-26 07:51:27 UTC
Bump the port revision so that it get rebuilt?
Comment 15 Li-Wen Hsu freebsd_committer freebsd_triage 2021-02-26 08:08:52 UTC
(In reply to Jakob Alvermark from comment #14)
According to comment #10 and comment #11 I suspect it doesn't need to rebuild, but updating libcxxrt.
Comment 16 Bengt Ahlgren 2021-02-26 08:24:48 UTC
libreoffice binaries built on 11.4-RELEASE still does not work on 11.4-STABLE after the libcxxrt updates. A change on stable branches should not require re-compilation of packages, or?
Comment 17 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2021-02-26 08:30:52 UTC
(In reply to Li-Wen Hsu from comment #15)

correct. all I did is rebuilt libcxxrt.
Comment 18 Li-Wen Hsu freebsd_committer freebsd_triage 2021-02-26 08:57:37 UTC
(In reply to Bengt Ahlgren from comment #16)
> libreoffice binaries built on 11.4-RELEASE still does not work on 11.4-STABLE after the libcxxrt updates. A change on stable branches should not require re-compilation of packages, or?

IIUC, it shouldn't.  If this is the case, this sounds a regression of stable/14 branch.  But just being curious, does rebuilding on 11.4-STABLE help?

Another thing I am worried is if this also happens on stable/12.
Comment 19 Bengt Ahlgren 2021-02-26 10:36:32 UTC
(In reply to Li-Wen Hsu from comment #18)
I can build libreoffice on 11.4-STABLE this weekend.  I will also try builds with default options - I currently have KF5 and JAVA on.
Comment 20 Nathan Whitehorn freebsd_committer freebsd_triage 2021-02-26 12:39:33 UTC
It also needs to be rebuilt -- it relies on some header file or static library or something. Just an update to libcxxrt.so does not fix the problem. The stable/13 packages are now affected too.
Comment 21 Dimitry Andric freebsd_committer freebsd_triage 2021-02-26 18:12:30 UTC
I've looked at the layout of struct _Unwind_Exception, which is declared in libcxxrt's unwind.h, and did some checks on the field offsets:

----------------------------------------------------------------------
amd64, before libcxxrt changes:

offsetof(_Unwind_Exception, exception_class)   = 0
offsetof(_Unwind_Exception, exception_cleanup) = 8
offsetof(_Unwind_Exception, private_1)         = 16
offsetof(_Unwind_Exception, private_2)         = 24
sizeof(_Unwind_Exception)                      = 32

amd64, after libcxxrt changes:

offsetof(_Unwind_Exception, exception_class)   = 0
offsetof(_Unwind_Exception, exception_cleanup) = 8
offsetof(_Unwind_Exception, private_1)         = 16
offsetof(_Unwind_Exception, private_2)         = 24
sizeof(_Unwind_Exception)                      = 32


i386, before libcxxrt changes:

offsetof(_Unwind_Exception, exception_class)   = 0
offsetof(_Unwind_Exception, exception_cleanup) = 8
offsetof(_Unwind_Exception, private_1)         = 12
offsetof(_Unwind_Exception, private_2)         = 16
sizeof(_Unwind_Exception)                      = 20

i386, after libcxxrt changes:

offsetof(_Unwind_Exception, exception_class)   = 0
offsetof(_Unwind_Exception, exception_cleanup) = 8
offsetof(_Unwind_Exception, private_1)         = 12
offsetof(_Unwind_Exception, private_2)         = 16
offsetof(_Unwind_Exception, reserved)          = 20
sizeof(_Unwind_Exception)                      = 32
----------------------------------------------------------------------

So in short, only on i386 has the struct become bigger, but this shouldn't influence any callers. (At least, if they aren't crazy enough to attempt to allocate and fill these by themselves... But libreoffice might be crazy enough)
Comment 22 Bengt Ahlgren 2021-02-28 17:10:28 UTC
I have built libreoffice in an 11-STABLE poudriere jail. That package does also work on 11-STABLE.  (Turning off KF5 and JAVA on an 11.4-REL build did not make a difference.)
Comment 23 Bengt Ahlgren 2021-02-28 17:59:25 UTC
I grepped a little in the libreoffice source.  The libreoffice header file bridges/source/cpp_uno/gcc3_ios/unwind-cxx.h includes the _Unwind_Exception as the last member of its own exception struct (__cxa_exception).  The update of libcxxrt changes the size this struct and the offset to the _Unwind_Exception member like this:

amd64 (11-STABLE), before libcxxrt changes:

sizeof(__cxa_exception)=120
offsetof(__cxa_exception, unwindHeader)=88

amd64 (11-STABLE), after libcxxrt changes:

sizeof(__cxa_exception)=128
offsetof(__cxa_exception, unwindHeader)=96

I have however no idea of the consequences...
Comment 24 Bengt Ahlgren 2021-02-28 18:48:26 UTC
I'm not sure that libreoffice header file is at all relevant, but the same applies to the __cxa_exception struct defined in the system header file:

/usr/include/c++/v1/cxxabi.h
Comment 25 Thomas Zander freebsd_committer freebsd_triage 2021-03-07 07:16:56 UTC
(In reply to Li-Wen Hsu from comment #18)

Sadly, I can confirm that I see the same thing on stable/12.
Comment 26 commit-hook freebsd_committer freebsd_triage 2021-03-10 21:51:46 UTC
A commit in branch stable/12 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=3ef7b71f3b7739cdb556e7419e7e66a865ca83f3

commit 3ef7b71f3b7739cdb556e7419e7e66a865ca83f3
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-03-10 21:31:40 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-03-10 21:31:40 +0000

    Partially revert libcxxrt changes to avoid _Unwind_Exception change

    After the recent cherry-picking of libcxxrt commits 0ee0dbfb0d26 and
    d2b3fadf2db5, users reported that editors/libreoffice packages from the
    official package builders did not start anymore. It turns out that the
    combination of these commits subtly changes the ABI, requiring all
    applications that depend on internal details of struct _Unwind_Exception
    (available via unwind-arm.h and unwind-itanium.h) to be recompiled.

    However, the FreeBSD package builders always use -RELEASE jails, so
    these still use the old declaration of struct _Unwind_Exception, which
    is not entirely compatible. In particular, LibreOffice uses this struct
    in its internal "uno bridge" component, where it attempts to setup its
    own exception handling mechanism.

    To fix this incompatibility, go back to the old declarations of struct
    _Unwind_Exception, and restore the __LP64__ specific workaround we had
    in place before (which was to cope with yet another, older ABI bug).

    Effectively, this reverts upstream libcxxrt commits 88bdf6b290da
    ("Specify double-word alignment for ARM unwind") and b96169641f79
    ("Updated Itanium unwind"), and reapplies our commit 3c4fd2463bb2
    ("libcxxrt: add padding in __cxa_allocate_* to fix alignment").

    PR:             253840

 contrib/libcxxrt/exception.cc     | 30 ++++++++++++++++++++++++------
 contrib/libcxxrt/unwind-arm.h     |  2 +-
 contrib/libcxxrt/unwind-itanium.h |  9 +++------
 3 files changed, 28 insertions(+), 13 deletions(-)
Comment 27 commit-hook freebsd_committer freebsd_triage 2021-03-10 21:53:49 UTC
A commit in branch stable/11 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=3a5074327da0ceba770aef60e41e91dc7d054019

commit 3a5074327da0ceba770aef60e41e91dc7d054019
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-03-10 21:32:18 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-03-10 21:32:18 +0000

    Partially revert libcxxrt changes to avoid _Unwind_Exception change

    After the recent cherry-picking of libcxxrt commits 0ee0dbfb0d26 and
    d2b3fadf2db5, users reported that editors/libreoffice packages from the
    official package builders did not start anymore. It turns out that the
    combination of these commits subtly changes the ABI, requiring all
    applications that depend on internal details of struct _Unwind_Exception
    (available via unwind-arm.h and unwind-itanium.h) to be recompiled.

    However, the FreeBSD package builders always use -RELEASE jails, so
    these still use the old declaration of struct _Unwind_Exception, which
    is not entirely compatible. In particular, LibreOffice uses this struct
    in its internal "uno bridge" component, where it attempts to setup its
    own exception handling mechanism.

    To fix this incompatibility, go back to the old declarations of struct
    _Unwind_Exception, and restore the __LP64__ specific workaround we had
    in place before (which was to cope with yet another, older ABI bug).

    Effectively, this reverts upstream libcxxrt commits 88bdf6b290da
    ("Specify double-word alignment for ARM unwind") and b96169641f79
    ("Updated Itanium unwind"), and reapplies our commit 3c4fd2463bb2
    ("libcxxrt: add padding in __cxa_allocate_* to fix alignment").

    PR:             253840

 contrib/libcxxrt/exception.cc     | 30 ++++++++++++++++++++++++------
 contrib/libcxxrt/unwind-arm.h     |  2 +-
 contrib/libcxxrt/unwind-itanium.h |  9 +++------
 3 files changed, 28 insertions(+), 13 deletions(-)
Comment 28 Dimitry Andric freebsd_committer freebsd_triage 2021-03-10 22:05:58 UTC
After these, libreoffice packages from the official package builders should work again. If you have built those packages (or the ports) yourself on stable/11 or stable/12, you unfortunately have to rebuild them again after updating your world.
Comment 29 Bengt Ahlgren 2021-03-11 12:07:36 UTC
(In reply to Dimitry Andric from comment #28)
I confirm that libreoffice executables from 11.4-RELEASE work again on 11.4-STABLE!

Thanks for taking care of this!
Comment 30 Dimitry Andric freebsd_committer freebsd_triage 2021-03-11 12:18:05 UTC
(In reply to Bengt Ahlgren from comment #29)
Glad to hear it! Now we need to make sure that the "bad" _Unwind_Exception struct does not make it into 13.0-RELEASE, otherwise we'll be stuck with it forever...
Comment 31 commit-hook freebsd_committer freebsd_triage 2021-03-13 13:55:36 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=9097e3cbcac455eb0dedd097d8d5548c72568d0a

commit 9097e3cbcac455eb0dedd097d8d5548c72568d0a
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-03-13 13:54:24 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-03-13 13:54:24 +0000

    Partially revert libcxxrt changes to avoid _Unwind_Exception change

    (Note I am also applying this to main and stable/13, to restore the old
    libcxxrt ABI and to avoid having to maintain a compat library.)

    After the recent cherry-picking of libcxxrt commits 0ee0dbfb0d26 and
    d2b3fadf2db5, users reported that editors/libreoffice packages from the
    official package builders did not start anymore. It turns out that the
    combination of these commits subtly changes the ABI, requiring all
    applications that depend on internal details of struct _Unwind_Exception
    (available via unwind-arm.h and unwind-itanium.h) to be recompiled.

    However, the FreeBSD package builders always use -RELEASE jails, so
    these still use the old declaration of struct _Unwind_Exception, which
    is not entirely compatible. In particular, LibreOffice uses this struct
    in its internal "uno bridge" component, where it attempts to setup its
    own exception handling mechanism.

    To fix this incompatibility, go back to the old declarations of struct
    _Unwind_Exception, and restore the __LP64__ specific workaround we had
    in place before (which was to cope with yet another, older ABI bug).

    Effectively, this reverts upstream libcxxrt commits 88bdf6b290da
    ("Specify double-word alignment for ARM unwind") and b96169641f79
    ("Updated Itanium unwind"), and reapplies our commit 3c4fd2463bb2
    ("libcxxrt: add padding in __cxa_allocate_* to fix alignment").

    PR:             253840

 contrib/libcxxrt/exception.cc     | 30 ++++++++++++++++++++++++------
 contrib/libcxxrt/unwind-arm.h     |  2 +-
 contrib/libcxxrt/unwind-itanium.h |  9 +++------
 3 files changed, 28 insertions(+), 13 deletions(-)
Comment 32 commit-hook freebsd_committer freebsd_triage 2021-03-13 13:55:38 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=0b45290603b9d294dc2fbbf6d7b8fa20acd60175

commit 0b45290603b9d294dc2fbbf6d7b8fa20acd60175
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-03-13 13:54:05 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-03-13 13:54:05 +0000

    Partially revert libcxxrt changes to avoid _Unwind_Exception change

    (Note I am also applying this to main and stable/13, to restore the old
    libcxxrt ABI and to avoid having to maintain a compat library.)

    After the recent cherry-picking of libcxxrt commits 0ee0dbfb0d26 and
    d2b3fadf2db5, users reported that editors/libreoffice packages from the
    official package builders did not start anymore. It turns out that the
    combination of these commits subtly changes the ABI, requiring all
    applications that depend on internal details of struct _Unwind_Exception
    (available via unwind-arm.h and unwind-itanium.h) to be recompiled.

    However, the FreeBSD package builders always use -RELEASE jails, so
    these still use the old declaration of struct _Unwind_Exception, which
    is not entirely compatible. In particular, LibreOffice uses this struct
    in its internal "uno bridge" component, where it attempts to setup its
    own exception handling mechanism.

    To fix this incompatibility, go back to the old declarations of struct
    _Unwind_Exception, and restore the __LP64__ specific workaround we had
    in place before (which was to cope with yet another, older ABI bug).

    Effectively, this reverts upstream libcxxrt commits 88bdf6b290da
    ("Specify double-word alignment for ARM unwind") and b96169641f79
    ("Updated Itanium unwind"), and reapplies our commit 3c4fd2463bb2
    ("libcxxrt: add padding in __cxa_allocate_* to fix alignment").

    PR:             253840

 contrib/libcxxrt/exception.cc     | 30 ++++++++++++++++++++++++------
 contrib/libcxxrt/unwind-arm.h     |  2 +-
 contrib/libcxxrt/unwind-itanium.h |  9 +++------
 3 files changed, 28 insertions(+), 13 deletions(-)
Comment 33 Nathan Whitehorn freebsd_committer freebsd_triage 2021-04-01 13:43:52 UTC
This is either broken again or the package build nodes have an old OS installed for -CURRENT.
Comment 34 Dimitry Andric freebsd_committer freebsd_triage 2021-04-01 17:58:58 UTC
(In reply to Nathan Whitehorn from comment #33)
Which packages are you installing? I'm unsure how to trace the origin of packages exactly.
Comment 35 Nathan Whitehorn freebsd_committer freebsd_triage 2021-04-01 18:57:08 UTC
(In reply to Dimitry Andric from comment #34)

Just whichever I get from "pkg upgrade" (14-CURRENT latest). I'm not sure where they come from, exactly, either.
Comment 36 Dimitry Andric freebsd_committer freebsd_triage 2021-04-04 11:10:25 UTC
(In reply to Nathan Whitehorn from comment #35)
The latest overview I have been able to find (thanks to bapt) is:
http://beefy18.nyi.freebsd.org/build.html?mastername=main-amd64-default&build=p569609_s4084b1ab04

The libreoffice-7.1.1.2_4 package has this build log:
http://beefy18.nyi.freebsd.org/data/main-amd64-default/p569609_s4084b1ab04/logs/libreoffice-7.1.1.2_4.log

with:
Host OSVERSION: 1400003
Jail OSVERSION: 1400006

and the jail is apparently at: https://cgit.freebsd.org/src/commit/?id=4084b1ab04
(as of 2021-03-31 20:59:10 +0000).

So that would certainly have the commit from comment #31 in it?