I bumped into this problem, as described in the issue https://github.com/CloudI/CloudI/issues/229 . To avoid it, I used clang for compilation and both linking with '-rtlib=compiler-rt -unwindlib=libunwind' and '-unwindlib=libgcc' was able to avoid the segfault. I also didn't see the segfault occur when using a Ubuntu 22.04 LTS VM in VirtualBox with (nongnu) libunwind 1.3.2, though the VM execution only provides slower execution of the C++ throw that leads to the libunwind segfault (i.e., it may not be able to replicate the failure due to being slower).
It would be nice if Ubuntu 20.04 updated nongnu libunwind to 1.3.2 or 1.6.2 to avoid causing problems for other people, even if this situation is unusual. The issue linked above describes how to replicate the problem (the execution takes less than 2 minutes to get a segfault). ** Bug watch added: github.com/CloudI/CloudI/issues #229 https://github.com/CloudI/CloudI/issues/229 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to google-glog in Ubuntu. https://bugs.launchpad.net/bugs/1960005 Title: Exceptions crash Status in google-glog package in Ubuntu: Confirmed Status in libunwind package in Ubuntu: Confirmed Bug description: There is a serious bug in libunwind 1.2.1 on Ubuntu 20.04 which causes a crash when handling exceptions (C++ in my case). I have observed libunwind incorrectly restoring registers while executing DWARF opcodes in .eh_frame. In my case, the restore of the register r6 (rbp on x86-64) was prematurely commited. In certain complex scenarios with optimization enabled, gcc emits DWARF instructions which express the offsets for save addresses of higher-numbered registers against rbp (instead of against the canonical frame address, as is usual). If rbp is prematurely committed, higher-numbered registers are restored incorrectly, i.e. corrupted. I have described the issue in great detail at https://gcc.gnu.org/pipermail/gcc-help/2022-February/141189.html The current version on Arch (1.6.x) seems to have this bug fixed. I don’t known at which point or which bug was it exactly, but it would be a really good idea to backport this fix. In my case, my application had libunwind linked in instead of using the builting gcc unwinder due to a 3rd party dependency, Google glog, used by the Google Ceres solver. However, it is only an optional dependency, and glog can be built without libunwind (it is just the preferred unwinder for printing stack dumps in glog). I had to rebuild glog without libunwind to stop my application from crashing (the builtin gcc unwinder works fine). Google has a strict policy against using C++ exceptions so I’m not surprised that they haven’t stumbled upon this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/google-glog/+bug/1960005/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
