summaryrefslogtreecommitdiff
path: root/issues/production-container-mechanical-rob-failure.gmi
diff options
context:
space:
mode:
Diffstat (limited to 'issues/production-container-mechanical-rob-failure.gmi')
-rw-r--r--issues/production-container-mechanical-rob-failure.gmi44
1 files changed, 25 insertions, 19 deletions
diff --git a/issues/production-container-mechanical-rob-failure.gmi b/issues/production-container-mechanical-rob-failure.gmi
index 7839943..a32194e 100644
--- a/issues/production-container-mechanical-rob-failure.gmi
+++ b/issues/production-container-mechanical-rob-failure.gmi
@@ -63,7 +63,7 @@ Your assistance in bug reporting will enable us to fix this for the next release
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,
+diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.5.23-MariaDB-0+deb11u1-log source revision: 6cfd2ba397b0ca689d8ff1bdb9fc4a4dc516a5eb
@@ -72,7 +72,7 @@ read_buffer_size=131072
max_used_connections=1
max_threads=2050
thread_count=1
-It is possible that mysqld could use up to
+It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4523497 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
@@ -139,23 +139,23 @@ information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /export/mysql/var/lib/mysql
Resource Limits:
-Limit Soft Limit Hard Limit Units
-Max cpu time unlimited unlimited seconds
-Max file size unlimited unlimited bytes
-Max data size unlimited unlimited bytes
-Max stack size 8388608 unlimited bytes
-Max core file size 0 unlimited bytes
-Max resident set unlimited unlimited bytes
-Max processes 3094157 3094157 processes
-Max open files 64000 64000 files
-Max locked memory 65536 65536 bytes
-Max address space unlimited unlimited bytes
-Max file locks unlimited unlimited locks
-Max pending signals 3094157 3094157 signals
-Max msgqueue size 819200 819200 bytes
-Max nice priority 0 0
-Max realtime priority 0 0
-Max realtime timeout unlimited unlimited us
+Limit Soft Limit Hard Limit Units
+Max cpu time unlimited unlimited seconds
+Max file size unlimited unlimited bytes
+Max data size unlimited unlimited bytes
+Max stack size 8388608 unlimited bytes
+Max core file size 0 unlimited bytes
+Max resident set unlimited unlimited bytes
+Max processes 3094157 3094157 processes
+Max open files 64000 64000 files
+Max locked memory 65536 65536 bytes
+Max address space unlimited unlimited bytes
+Max file locks unlimited unlimited locks
+Max pending signals 3094157 3094157 signals
+Max msgqueue size 819200 819200 bytes
+Max nice priority 0 0
+Max realtime priority 0 0
+Max realtime timeout unlimited unlimited us
Core pattern: core
Kernel version: Linux version 5.10.0-22-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.178-3 (2023-04-22)
@@ -216,3 +216,9 @@ Huh, so this was not a code problem.
Configured database to allow upgrade of tables if necessary and restarted mariadbd.
The problem still persists.
+
+Note Pjotr: this is likely a mariadb bug with 10.5.23, the most recent mariadbd we use (both tux01 and tux02 are older). The dump shows it balks on creating a new thread: pthread_create.c:478. Looks similar to https://jira.mariadb.org/browse/MDEV-32262
+
+10.5, 10.6, 10.11 are affected. so running correlations on production crashes mysqld? I am not trying for obvious reasons ;) the threading issues of mariadb look scary - I wonder how deep it goes.
+
+We'll test for a different version of mariadb combining a Debian update because Debian on tux04 is broken.