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

[Christian Ehrhardt ]

Ok I found in the stdc++ implementation of "new" that sz indeed is passed to malloc.
  void *ptr = std::malloc(sz))
Thereby it indeed means "bytes" and that means ~18 exabyte which is slightly more than most systems can offer :-)

The question now becomes, where is this value created/derived from and
can we reproduce this maybe even outside of the complexity of mysql. To
me it starts to seem more like an issue in the lib, but to know that for
sure we will need to track down where this value really comes from.

-- 
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