Performing verification for Bionic.

I started two instances on AWS, one c6g.medium (arm64) and a t2.micro
(amd64).

I went through the reproducer listed in the testcase with libunwind-dev
1.2.1-8 from -release.

$ wget 
https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+attachment/5635122/+files/libunwind.tar.gz
$ sudo apt install -y build-essential libunwind-dev
$ tar xvf libunwind.tar.gz && cd test
test/
test/lib.hpp
test/main.cpp
test/lib.cpp
test/Makefile
~/test$ make all
g++ -g -shared-libgcc -shared -fPIC -std=c++11 -o libtest.so lib.cpp
g++ -g -shared-libgcc -o main -L. -Wl,-rpath,. main.cpp -ltest
g++ -g -shared-libgcc -o main_unwind -L. -Wl,-rpath,.  main.cpp -ltest -lunwind

On arm64:

~/test$ ./main
int throws lib
int caught main
~/test$ ./main_unwind
terminate called after throwing an instance of 'int'
terminate called recursively
Aborted (core dumped)

On amd64:

~/test$ ./main
int throws lib
int caught main
~/test$ ./main_unwind
int throws lib
int caught main

As expected, we see arm64 abort the execution of the reproducer.

I then installed 1.2.1-8ubuntu0.1 from -proposed and rebuilt the
reproducers:

$ make clean
$ make all
g++ -g -shared-libgcc -shared -fPIC -std=c++11 -o libtest.so lib.cpp
g++ -g -shared-libgcc -o main -L. -Wl,-rpath,. main.cpp -ltest
g++ -g -shared-libgcc -o main_unwind -L. -Wl,-rpath,.  main.cpp -ltest -lunwind

On arm64:

$ ./main
int throws lib
int caught main
$ ./main_unwind
int throws lib
int caught main

On amd64:

~/test$ ./main
int throws lib
int caught main
~/test$ ./main_unwind
int throws lib
int caught main

We see that 1.2.1-8ubuntu0.1 from -proposed does not abort, and instead
runs as expected. There is no change in behaviour on amd64. The package
in -proposed fixes the problem, happy to mark as verified for Bionic.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libunwind in Ubuntu.
https://bugs.launchpad.net/bugs/1999104

Title:
  arm64: broken c++ exception handler support leads to std::terminate()
  being called and program abort

Status in libunwind package in Ubuntu:
  Fix Released
Status in libunwind source package in Bionic:
  Fix Committed
Status in libunwind source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  On architectures other than i386 and amd64, the C++ exception support
  in libunwind appears to be broken, always failing and calling
  std::terminate() which leads to the program aborting.

  (gdb) bt
  #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
  #1  0x0000fffff7c2daac in __GI_abort () at abort.c:79
  #2  0x0000fffff7e21868 in __gnu_cxx::__verbose_terminate_handler() ()
     from /lib/aarch64-linux-gnu/libstdc++.so.6
  #3  0x0000fffff7e1f21c in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6
  #4  0x0000fffff7e1f280 in std::terminate() ()
     from /lib/aarch64-linux-gnu/libstdc++.so.6
  #5  0x0000fffff7e1f5e0 in __cxa_rethrow ()
     from /lib/aarch64-linux-gnu/libstdc++.so.6
  #6  0x0000fffff7e21804 in __gnu_cxx::__verbose_terminate_handler() ()
     from /lib/aarch64-linux-gnu/libstdc++.so.6
  #7  0x0000fffff7e1f21c in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6
  #8  0x0000fffff7e1f280 in std::terminate() ()
     from /lib/aarch64-linux-gnu/libstdc++.so.6
  #9  0x0000fffff7e1f574 in __cxa_throw ()
     from /lib/aarch64-linux-gnu/libstdc++.so.6
  #10 0x0000fffff7fb9f50 in function_throws_int () at lib.cpp:9
  #11 0x0000aaaaaaaa0d54 in main (argc=1, argv=0xfffffffffab8) at main.cpp:9

  Compiling libunwind with --enable-cxx-exceptions enabled leads to
  _Unwind_RaiseException being called during __cxa_throw(), which fails
  to find a handler, and the generic std::terminate() is called instead,
  aborting the program.

  On i386 and amd64 this doesn't seem to be the case, and the libunwind
  handlers seem to be present.

  To fix, we only enable the configure option --enable-cxx-exceptions on
  i386 and amd64 only, in debian/rules. This lets other architectures
  fall back to the symbols provided by libgcc_s, which implementation
  works correctly.

  [Testcase]

  Ali Sadi has provided a reproducer program.

  Start an arm64 instance, for example, a c6g.medium instance on AWS,
  with either Bionic or Focal.

  $ wget 
https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+attachment/5635122/+files/libunwind.tar.gz
  $ sudo apt install -y build-essential libunwind-dev
  $ tar xvf libunwind.tar.gz && cd test
  $ make all

  There are two executable, main and main_unwind. main is not linked to
  libunwind, and main_unwind is linked to libunwind.

  $ ./main
  int throws lib
  int caught main
  $ ./main_unwind
  terminate called after throwing an instance of 'int'
  terminate called recursively
  Aborted (core dumped)

  If you install the test package available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf350246-test

  $ make clean
  $ sudo apt install -y libunwind-dev
  $ make all
  $ ./main
  int throws lib
  int caught main
  $ ./main_unwind
  int throws lib
  int caught main

  The exception is caught as expected the program does not abort.

  [Where problems could occur]

  For architectures other than i386 and amd64, we are changing from
  libunwind provided exception handlers for __cxa_throw(), and using
  those provided by libgcc_s instead.

  There are a few reverse dependencies for libunwind-dev and libunwind8,
  which need to be considered:

  $ apt rdepends libunwind-dev
  libunwind-dev
  Reverse Depends:
    Depends: libunwind-setjmp0-dev (= 1.2.1-9build1)
    Depends: libefl-all-dev

  t$ apt rdepends libunwind-dev    8
  libunwind8
  Reverse Depends:
    Depends: libunwind-dev (= 1.2.1-9build1)
    Depends: xvfb
    Depends: xnest
    Depends: xdmx
    Depends: xwayland
    Depends: xserver-xorg-core
    Depends: xserver-xephyr
    Depends: linux-tools-5.4.0-*
    Depends: linux-raspi-tools-*
    Depends: linux-raspi2-tools-5.4.0-*
    Depends: linux-raspi2-5.4-tools-5.4.0-*
    Depends: linux-oracle-5.15-tools-5.15.0-*
    Depends: linux-lowlatency-hwe-5.15-tools-5.15.0-*
    Depends: linux-hwe-5.8-tools-5.8.0-*
    Depends: linux-hwe-5.15-tools-5.15.0-*
    Depends: linux-gke-tools-5.4.0-*
    Depends: linux-gke-5.15-tools-5.15.0-*
    Depends: linux-gcp-tools-5.4.0-*
    Depends: linux-gcp-5.15-tools-5.15.0-*
    Depends: linux-azure-tools-5.4.0-*
    Depends: linux-azure-5.15-tools-5.15.0-*
    Depends: linux-aws-tools-5.4.0-*
    Depends: linux-aws-5.8-tools-5.8.0-*
    Depends: linux-aws-5.15-tools-5.15.0-*
    Depends: xvfb
    Depends: xnest
    Depends: xdmx
    Depends: trafficserver
    Depends: tilix
    Depends: tigervnc-standalone-server
    Depends: tarantool
    Depends: sysprof
    Depends: rspamd
    Depends: libwine-development
    Depends: libwine
    Depends: libjulia1
    Depends: libheaptrack
    Depends: libevas-loaders
    Depends: libephysics1
    Depends: libeina1a
    Depends: libecore-imf1
    Depends: julia
    Depends: geary
    Depends: gdnsd
    Depends: xwayland
    Depends: xserver-xorg-core
    Depends: xserver-xephyr
    Depends: libunwind-setjmp0

  The reporter seems to be hitting the issue with mcrouter, built
  themselves, so we can likely skip no-change rebuilds of rdepends until
  we get actual complaints that a bug exists in those packages, to keep
  regression risk down.

  This does of course, leave the risk of regression to the future,
  especially during critical times, e.g. CVE fix.

  [Other info]

  This was resolved in Debian bug 923962 by the maintainer, by setting
  the configure option --enable-cxx-exceptions only on i386 and amd64.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923962

  The debdiff between Focal and Groovy is available here:

  https://paste.ubuntu.com/p/8xv6FNPs8g/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+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

Reply via email to