[Bug 1915275] Re: mysql-8.0 regressed on riscv64 due to new glibc

Christian Ehrhardt  1915275 at bugs.launchpad.net
Thu Mar 11 11:03:17 UTC 2021


>From the backtrace at frist we see:

At the start of mysql it calls init_server_components -> delegates_init.
That then initializes a new object
  alignas(Trans_delegate) static char place_trans_mem[sizeof(Trans_delegate)];
  ...
  transaction_delegate = new (place_trans_mem) Trans_delegate;

That then triggers the allocation of a lock::Shared_spin_lock::Shared_spin_lock
Which itself uses the default constructor:
  Shared_spin_lock() = default;

That then goes into memory::Aligned_atomic<long>::Aligned_atomic

There (at least to my naive view) it seems to go terribly wrong with it's size assumptions because if sz is the size in bytes then 
  #6  0x0000003ff76389b8 in operator new (sz=18446744073709551615)
clearly is too much.

...
#6  0x0000003ff76389b8 in operator new (sz=18446744073709551615)
    at ../../../../src/libstdc++-v3/libsupc++/new_op.cc:54
        handler = <optimized out>
        p = <optimized out>
#7  0x0000003ff76389d6 in operator new[] (sz=<optimized out>)
    at ../../../../src/libstdc++-v3/libsupc++/new_opv.cc:32
No locals.
#8  0x0000002aac352ed8 in memory::Aligned_atomic<long>::Aligned_atomic (
    this=0x2aae2463d0 <delegates_init()::place_trans_mem+112>)
    at ./sql/memory/aligned_atomic.h:282
No locals.
#9  memory::Aligned_atomic<long>::Aligned_atomic (value=0, 
    this=0x2aae2463d0 <delegates_init()::place_trans_mem+112>)
    at ./sql/memory/aligned_atomic.h:287
...

** Attachment added: "Backtrace of the issue in Hirsute rsicv64"
   https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1915275/+attachment/5475790/+files/riscv64-libc2.33-hirsute-crash.backtrace

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1915275

Title:
  mysql-8.0 regressed on riscv64 due to new glibc

Status in glibc package in Ubuntu:
  New
Status in mysql-8.0 package in Ubuntu:
  Confirmed
Status in php7.4 package in Ubuntu:
  New

Bug description:
  Hello, looks like mysql-8.0 can't run anymore its testsuite on riscv64, due to a probable bug in glibc.
  See e.g.
  https://launchpad.net/ubuntu/+source/mysql-8.0/8.0.23-1ubuntu1/+build/20983618

  I'm currently building on bileto with release pocket, to have a fast migration, because this is blocking some reverse-dependencies such as boinc from building correctly on riscv64.
  make[1]: Entering directory '/<<PKGBUILDDIR>>'
  RULES.override_dh_auto_test
  touch builddir/mysql-test/skiplist
  # Tests that are known to be unstable on all platforms are skipped
  # http://bugs.mysql.com/bug.php?id=83340
  echo "main.xa_prepared_binlog_off	: BUG#00000 - unstable test" >> builddir/mysql-test/skiplist
  echo "main.mysql_client_test		: BUG#100274 - unstable test" >> builddir/mysql-test/skiplist
  echo "main.type_float			: BUG#92375 - fails on ppc64el. Ref https://bugs.mysql.com/bug.php?id=92375" >> builddir/mysql-test/skiplist
  echo "main.type_newdecimal		: BUG#92375 - Same as above" >> builddir/mysql-test/skiplist
  echo "main.type_ranges			: BUG#92375 - Same as above" >> builddir/mysql-test/skiplist
  # https://bugs.mysql.com/bug.php?id=86608
  echo "main.mysqlpump_basic		: BUG#00000 - needs openssl with zlib" >> builddir/mysql-test/skiplist
  # Test is broken for 32bit. Fixed upstream, so remove in 8.0.12+
  echo "main.window_functions_explain	: BUG#00000 -  broken on i386" >> builddir/mysql-test/skiplist
  # Skip replication tests since they are timing sensitive and may
  # result in false positives.
  cd builddir/mysql-test && ./mtr --report-unstable-tests --parallel=8 --skip-rpl --suite=main --force --skip-test-list=./skiplist || true ;
  Logging: /<<PKGBUILDDIR>>/mysql-test/mysql-test-run.pl  --report-unstable-tests --parallel=8 --skip-rpl --suite=main --force --skip-test-list=./skiplist
  terminate called after throwing an instance of 'std::bad_alloc'
    what():  std::bad_alloc
  18:50:20 UTC - mysqld got signal 6 ;
  Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
  Thread pointer: 0x0
  Attempting backtrace. You can use the following information to find out
  where mysqld died. If you see no messages after this, something went
  terribly wrong...
  stack_bottom = 0 thread_stack 0x46000
  /<<PKGBUILDDIR>>/builddir/runtime_output_directory/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x62) [0x2aac5bb7d0]
  /<<PKGBUILDDIR>>/builddir/runtime_output_directory/mysqld(handle_fatal_signal+0x270) [0x2aab942e64]
  linux-vdso.so.1(__vdso_rt_sigreturn+0) [0x3ff7fe0800]
  /lib/riscv64-linux-gnu/libc.so.6(gsignal+0xa2) [0x3ff7420fec]
  /lib/riscv64-linux-gnu/libc.so.6(abort+0xb4) [0x3ff741198c]
  The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
  information that should help you find out what is causing the crash.
  mysql-test-run: *** ERROR: Could not find version of MySQL
  cd builddir/mysql-test && ./mtr --report-unstable-tests --force innodb_fts.mecab_utf8
  Logging: /<<PKGBUILDDIR>>/mysql-test/mysql-test-run.pl  --report-unstable-tests --force innodb_fts.mecab_utf8
  terminate called after throwing an instance of 'std::bad_alloc'
    what():  std::bad_alloc
  18:50:24 UTC - mysqld got signal 6 ;
  Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
  Thread pointer: 0x0
  Attempting backtrace. You can use the following information to find out
  where mysqld died. If you see no messages after this, something went
  terribly wrong...
  stack_bottom = 0 thread_stack 0x46000
  /<<PKGBUILDDIR>>/builddir/runtime_output_directory/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x62) [0x2aac5bb7d0]
  /<<PKGBUILDDIR>>/builddir/runtime_output_directory/mysqld(handle_fatal_signal+0x270) [0x2aab942e64]
  linux-vdso.so.1(__vdso_rt_sigreturn+0) [0x3ff7fe0800]
  /lib/riscv64-linux-gnu/libc.so.6(gsignal+0xa2) [0x3ff7420fec]
  /lib/riscv64-linux-gnu/libc.so.6(abort+0xb4) [0x3ff741198c]
  The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
  information that should help you find out what is causing the crash.
  mysql-test-run: *** ERROR: Could not find version of MySQL
  make[1]: *** [debian/rules:154: override_dh_auto_test] Error 1
  make[1]: Leaving directory '/<<PKGBUILDDIR>>'
  make: *** [debian/rules:226: build-arch] Error 2
  dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1915275/+subscriptions



More information about the foundations-bugs mailing list