Exceptions crash
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:/
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.
Status changed to 'Confirmed' because the bug affects multiple users.