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

[Christian Ehrhardt ]

I have separated the problem from all the mysql code.
This file here works on x86 and on older riscv64.
But if ran on current hirsute riscv64 it breaks as mysql-server-8.0 does.

I further simplified it and attach it hereby for debugging.
It seems that the detection of the cache-line-size is failing and from there things go south.

riscv64 @ Hirsute
CL 18446744073709551615
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

riscv64 @ Focal
CL 0
static 32 at 0x3fff86f2c0

x86 @ Hirsute
CL 64
static 32 at 0x7fff300363a0


So it seems what is broken is "sysconf(_SC_LEVEL1_DCACHE_LINESIZE);"
On some platforms that returns good values (e.g. x86) and on others it used to return "0".
Mysql had code to cover the "0" case, but the new libc at riscv64 we get a crazy high value and that  breaks all that we see.

** Attachment added: "test-riscv64-alloc.cpp"
   https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1915275/+attachment/5475843/+files/test-riscv64-alloc.cpp

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