| 2022-02-04 08:46:37 |
Juraj |
bug |
|
|
added bug |
| 2022-02-04 08:50:15 |
Juraj |
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 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, but it would
be a really good idea to backport this fix.
In my case, my application had libunwind linked in instead of
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).
Google has a strict policy against using C++ exceptions so I’m
not surprised that they haven’t stumbled upon this. |
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).
Google has a strict policy against using
C++ exceptions so I’m not surprised that
they haven’t stumbled upon this. |
|
| 2022-02-04 08:51:08 |
Juraj |
tags |
|
focal |
|
| 2022-02-04 08:53:56 |
Juraj |
bug task added |
|
google-glog (Ubuntu) |
|
| 2022-02-04 08:56:57 |
Juraj |
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).
Google has a strict policy against using
C++ exceptions so I’m not surprised that
they haven’t stumbled upon this. |
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. |
|
| 2023-06-29 20:24:08 |
Launchpad Janitor |
google-glog (Ubuntu): status |
New |
Confirmed |
|
| 2023-06-29 20:24:08 |
Launchpad Janitor |
libunwind (Ubuntu): status |
New |
Confirmed |
|
| 2023-06-29 20:45:08 |
Michael Truog |
bug watch added |
|
https://github.com/CloudI/CloudI/issues/229 |
|
