Bug 253840
| Summary: | editors/libreoffice: fails to start after update to 7.1.0.3_2 with "Application Error" | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Ruslan Makhmatkhanov <rm> | ||||
| Component: | Individual Port(s) | Assignee: | FreeBSD Office Team <office> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | bahlgren, dim, emaste, jakob, lwhsu, nwhitehorn, pstef, riggs | ||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(office) |
||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
Ruslan Makhmatkhanov
2021-02-25 09:21:29 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? Thanks for the info, will try. (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? 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. I'll try to update base (it's already contains the fix) and see how it's going. Thanks. 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 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?
(In reply to Bengt Ahlgren from comment #7) Hope dim@ can help answer this. :-) (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 ? 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 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. 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. 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. Bump the port revision so that it get rebuilt? (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. 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? (In reply to Li-Wen Hsu from comment #15) correct. all I did is rebuilt libcxxrt. (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. (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. 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. 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) 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.) 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... 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 (In reply to Li-Wen Hsu from comment #18) Sadly, I can confirm that I see the same thing on stable/12. 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(-) 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(-) 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. (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! (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... 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(-) 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(-) This is either broken again or the package build nodes have an old OS installed for -CURRENT. (In reply to Nathan Whitehorn from comment #33) Which packages are you installing? I'm unsure how to trace the origin of packages exactly. (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. (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? |