Public bug reported: 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. ** Affects: google-glog (Ubuntu) Importance: Undecided Status: New ** Affects: libunwind (Ubuntu) Importance: Undecided Status: New ** Tags: focal ** Description changed: - 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). + 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 + 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, but it would - be a really good idea to backport this fix. + 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 - 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). + 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. + Google has a strict policy against using + C++ exceptions so I’m not surprised that + they haven’t stumbled upon this. ** Tags added: focal ** Also affects: google-glog (Ubuntu) Importance: Undecided Status: New ** Description changed: - There is a serious bug in libunwind 1.2.1 on - Ubuntu 20.04 which causes a crash when + 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 + 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 + gcc emits DWARF instructions which express + the offsets for save addresses of higher-numbered registers against rbp - (instead of against the canonical frame + (instead of against the canonical frame address, as is usual). - If rbp is prematurely committed, + 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 + 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, + unwinder due to a 3rd party dependency, Google glog, used by the Google Ceres - solver. However, it is only an optional + 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1960005 Title: Exceptions crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/google-glog/+bug/1960005/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
