[debian-mysql] Bug#990763: mariadb-server-core-10.3: MariaDB 10.3.29 is crashing and restarting continuously

support at etes.de support at etes.de
Tue Jul 6 13:27:28 BST 2021


Package: mariadb-server-core-10.3
Version: 1:10.3.29-0+deb10u1
Severity: important

Dear Maintainer,

   * What led up to the situation?
     Upgrading mariadb-server-core-10.3 from 1:10.3.27-0+deb10u1 to 1:10.3.29-0+deb10u1 (we see this on two servers)
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
     Reconfigure mariadb to listen on localhost only, no more querys from the webserver were received
     mariadb stops crashing
     Checking all tables, no errors have been found
     Running sql-statement from mariadb error log in mariadb console does not led to an crash
     reconfigure to listen on network, mariadb is crashing again
     downgrade to 10.3.27-0+deb10u1, mariadb is running stable    
   * What was the outcome of this action?
     see obove
   * What outcome did you expect instead?
     we exptected that mariadb would not crash after updating to 10.3.29-0+deb10u1
   * error.log from mariadb
     
210702  0:02:26 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

Server version: 10.3.29-MariaDB-0+deb10u1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=12
max_threads=153
thread_count=13
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 352741 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7fb1d8007678
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 = 0x7fb230990dd8 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55c06f39631e]
/usr/sbin/mysqld(handle_fatal_signal+0x54d)[0x55c06eec157d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7fb234a9a730]
/usr/sbin/mysqld(_Z15optimize_keyuseP4JOINP16st_dynamic_array+0x160)[0x55c06ed17530]
/usr/sbin/mysqld(+0x61c373)[0x55c06ed36373]
/usr/sbin/mysqld(_ZN4JOIN14optimize_innerEv+0xa03)[0x55c06ed3ec73]
/usr/sbin/mysqld(_ZN4JOIN8optimizeEv+0x52)[0x55c06ed3eff2]
/usr/sbin/mysqld(_ZN13st_select_lex31optimize_unflattened_subqueriesEb+0x12d)[0x55c06eccf6dd]
/usr/sbin/mysqld(_ZN4JOIN15optimize_stage2Ev+0x1136)[0x55c06ed3cec6]
/usr/sbin/mysqld(_ZN4JOIN14optimize_innerEv+0xae6)[0x55c06ed3ed56]
/usr/sbin/mysqld(_ZN4JOIN8optimizeEv+0x52)[0x55c06ed3eff2]
/usr/sbin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x7a3)[0x55c06ed40da3]
/usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x14d)[0x55c06ed40ffd]
/usr/sbin/mysqld(+0x5c74ac)[0x55c06ece14ac]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x519f)[0x55c06eceda4f]
/usr/sbin/mysqld(_ZN18Prepared_statement7executeEP6Stringb+0x41e)[0x55c06ed028be]
/usr/sbin/mysqld(_ZN18Prepared_statement12execute_loopEP6StringbPhS2_+0x97)[0x55c06ed02aa7]
/usr/sbin/mysqld(+0x5e99b5)[0x55c06ed039b5]
/usr/sbin/mysqld(_Z19mysqld_stmt_executeP3THDPcj+0x2b)[0x55c06ed03aab]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x14ab)[0x55c06ecf243b]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x122)[0x55c06ecf3842]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x23a)[0x55c06edc617a]
/usr/sbin/mysqld(handle_one_connection+0x3d)[0x55c06edc62fd]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3)[0x7fb234a8ffa3]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fb2349c04cf]



-- System Information:
Debian Release: 10.10
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-17-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server-core-10.3 depends on:
ii  libaio1         0.3.112-3
ii  libc6           2.28-10
ii  libgnutls30     3.6.7-4+deb10u7
ii  liblz4-1        1.8.3-1+deb10u1
ii  libpcre3        2:8.39-12
ii  libsnappy1v5    1.1.7-1
ii  libstdc++6      8.3.0-6
ii  libsystemd0     241-7~deb10u7
ii  mariadb-common  1:10.3.29-0+deb10u1
ii  zlib1g          1:1.2.11.dfsg-1

mariadb-server-core-10.3 recommends no packages.

mariadb-server-core-10.3 suggests no packages.

-- no debconf information



More information about the pkg-mysql-maint mailing list