Exceptions crash

Bug #1960005 reported by Juraj
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
google-glog (Ubuntu)
Confirmed
Undecided
Unassigned
libunwind (Ubuntu)
Confirmed
Undecided
Unassigned

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.

Tags: focal
Juraj (ojura)
description: updated
tags: added: focal
Juraj (ojura)
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in google-glog (Ubuntu):
status: New → Confirmed
Changed in libunwind (Ubuntu):
status: New → Confirmed
Revision history for this message
Michael Truog (mjtruog-gmail) wrote :

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).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.