Docker image mariadb:latest in a K3s Kubernetes cluster on an Arch Linux machine
Description
MariaDB crashes when executing a query that tries to access a table information_schema.users
I haven't checked with other similar tables, but it surely does not happen with the tables "tables" and "columns" of the information_schema schema
Following is the stack trace:
[ERROR] mariadbd got signal 11 ;
Sorry, we probably made a mistake, and this is a bug.
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 about how to report
a bug on https://jira.mariadb.org/.
Please include the information from the server start above, to the end of the
information below.
Server version: 11.7.2-MariaDB-ubu2404 source revision: 80067a69feaeb5df30abb1bfaf7d4e713ccbf027
The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/
contains instructions to obtain a better version of the backtrace below.
Following these instructions will help MariaDB developers provide a fix quicker.
Attempting backtrace. Include this in the bug report.
I tried on this "SELECT * FROM sometable WHERE something=1 AND (SELECT 1 FROM information_schema.users) = 1" without preproduction, so it looks like this is part of the query and the rest of it is significant enough to cause the bug trigger. Do you have the rest of the query?
Daniel Black
added a comment - - edited I tried on this "SELECT * FROM sometable WHERE something=1 AND (SELECT 1 FROM information_schema.users) = 1" without preproduction, so it looks like this is part of the query and the rest of it is significant enough to cause the bug trigger. Do you have the rest of the query?
Here are some instructions and code to reproduce the bug in a (semi-)minimal setup. You can find a README.md with all the instructions to run this using Docker and Docker Compose. https://github.com/Golim/mariadb-reproduce-crash
Matteo Golinelli
added a comment - Here are some instructions and code to reproduce the bug in a (semi-)minimal setup. You can find a README.md with all the instructions to run this using Docker and Docker Compose. https://github.com/Golim/mariadb-reproduce-crash
Confirmed. Thanks for example. With --skip-grant-tables there isn't the full initialization to make this possible.
crash
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 87635.87680]
0x0000000000bb5f97 in pfs_unlock_mutex_v1 (mutex=0xa676f6c2e6374) at /home/dan/repos/mariadb-server-main/storage/perfschema/pfs.cc:3667
3667 pfs_mutex->m_last_locked= 0;
(rr) bt
#0 0x0000000000bb5f97 in pfs_unlock_mutex_v1 (mutex=0xa676f6c2e6374) at /home/dan/repos/mariadb-server-main/storage/perfschema/pfs.cc:3667
#1 0x00000000006e868d in inline_mysql_mutex_unlock (that=<optimized out>) at /home/dan/repos/mariadb-server-main/include/mysql/psi/mysql_thread.h:786
#2 0x00000000006e868d in fill_users_schema_table (thd=<optimized out>, tables=<optimized out>, cond=<optimized out>)
#3 0x00000000007eff21 in get_schema_tables_result (join=join@entry=0x7fbcdc030d90, executed_place=executed_place@entry=PROCESSED_BY_JOIN_EXEC) at /home/dan/repos/mariadb-server-main/sql/sql_show.cc:9716
#4 0x00000000007b0fb7 in JOIN::exec_inner (this=this@entry=0x7fbcdc030d90) at /home/dan/repos/mariadb-server-main/sql/sql_select.cc:5020
#5 0x00000000007982c8 in JOIN::exec (this=0x7fbcdc030d90) at /home/dan/repos/mariadb-server-main/sql/sql_select.cc:4842
fields=@0x7fbcdc02faa8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x7fbcdc010ef0, last = 0x7fbcdc010ef0, elements = 1}, <No data fields>}, conds=<optimized out>, og_num=<optimized out>,
at /home/dan/repos/mariadb-server-main/sql/sql_select.cc:5375
#7 0x0000000000797f89 in handle_select (thd=thd@entry=0x7fbcdc000fd8, lex=lex@entry=0x7fbcdc005250, result=result@entry=0x7fbcdc0110f0, setup_tables_done_option=setup_tables_done_option@entry=0)
at /home/dan/repos/mariadb-server-main/sql/sql_select.cc:633
#8 0x00000000007689bd in execute_sqlcom_select (thd=thd@entry=0x7fbcdc000fd8, all_tables=0x7fbcdc02fca8) at /home/dan/repos/mariadb-server-main/sql/sql_parse.cc:6191
#9 0x000000000076416a in mysql_execute_command (thd=thd@entry=0x7fbcdc000fd8, is_called_from_prepared_stmt=false) at /home/dan/repos/mariadb-server-main/sql/sql_parse.cc:3979
#10 0x000000000075fd2c in mysql_parse (thd=thd@entry=0x7fbcdc000fd8, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x7fbd037fd280)
at /home/dan/repos/mariadb-server-main/sql/sql_parse.cc:7915
#11 0x000000000075e476 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7fbcdc000fd8, packet=packet@entry=0x7fbcdc008c19 "SELECT 1 FROM information_schema.users",
packet_length=packet_length@entry=38, blocking=true) at /home/dan/repos/mariadb-server-main/sql/sql_parse.cc:1902
#12 0x0000000000760182 in do_command (thd=thd@entry=0x7fbcdc000fd8, blocking=true) at /home/dan/repos/mariadb-server-main/sql/sql_parse.cc:1415
#13 0x000000000087d24d in do_handle_one_connection (connect=<optimized out>, connect@entry=0x12096f58, put_in_cache=<optimized out>) at /home/dan/repos/mariadb-server-main/sql/sql_connect.cc:1415
#14 0x000000000087d08a in handle_one_connection (arg=arg@entry=0x12096f58) at /home/dan/repos/mariadb-server-main/sql/sql_connect.cc:1327
#15 0x0000000000bb4809 in pfs_spawn_thread (arg=0x120156d8) at /home/dan/repos/mariadb-server-main/storage/perfschema/pfs.cc:2198
#16 0x00007fbd1da7dba8 in start_thread () from /lib64/libc.so.6
#17 0x00007fbd1db01994 in clone () from /lib64/libc.so.6
#0 0x00007fd4bf480d72 in __pthread_mutex_lock_full () from /lib64/libc.so.6
No symbol table info available.
#1 0x00000000016f966f in safe_mutex_lock (mp=0x2bc37ae8, my_flags=0, file=0x1829c35 "/home/dan/repos/mariadb-server-main/sql/sql_acl.cc", line=13153) at /home/dan/repos/mariadb-server-main/mysys/thr_mutex.c:234
error = 25336885
#2 0x00000000016f4057 in psi_mutex_lock (that=0x2bc37ae8, file=0x1829c35 "/home/dan/repos/mariadb-server-main/sql/sql_acl.cc", line=13153) at /home/dan/repos/mariadb-server-main/mysys/my_thr_init.c:471
#3 0x00000000008a2a2c in inline_mysql_mutex_lock (that=0x2bc37ae8, src_file=0x1829c35 "/home/dan/repos/mariadb-server-main/sql/sql_acl.cc", src_line=13153) at /home/dan/repos/mariadb-server-main/include/mysql/psi/mysql_thread.h:746
No locals.
#4 0x00000000008c1268 in fill_users_schema_table (thd=0x7fd46c000dc8, tables=0x7fd46c035068, cond=0x0) at /home/dan/repos/mariadb-server-main/sql/sql_acl.cc:13153
res = 0
see_whole_table = true
table = 0x7fd46c03eaf0
#5 0x0000000000aa47cb in get_schema_tables_result (join=0x7fd46c0362f8, executed_place=PROCESSED_BY_JOIN_EXEC) at /home/dan/repos/mariadb-server-main/sql/sql_show.cc:9716
#9 0x0000000000a18e11 in handle_select (thd=0x7fd46c000dc8, lex=0x7fd46c005210, result=0x7fd46c0362d0, setup_tables_done_option=0) at /home/dan/repos/mariadb-server-main/sql/sql_select.cc:633
#10 0x00000000009b889a in execute_sqlcom_select (thd=0x7fd46c000dc8, all_tables=0x7fd46c035068) at /home/dan/repos/mariadb-server-main/sql/sql_parse.cc:6191
save_protocol = 0x0
lex = 0x7fd46c005210
result = 0x7fd46c0362d0
res = false
#11 0x00000000009ae636 in mysql_execute_command (thd=0x7fd46c000dc8, is_called_from_prepared_stmt=false) at /home/dan/repos/mariadb-server-main/sql/sql_parse.cc:3979
#12 0x00000000009a5f97 in mysql_parse (thd=0x7fd46c000dc8, rawbuf=0x7fd46c0349f0 "select 1 from information_schema.users", length=38, parser_state=0x7fd4b80925b0) at /home/dan/repos/mariadb-server-main/sql/sql_parse.cc:7915
#13 0x00000000009a2b70 in dispatch_command (command=COM_QUERY, thd=0x7fd46c000dc8, packet=0x7fd46c00bca9 "select 1 from information_schema.users", packet_length=38, blocking=true) at /home/dan/repos/mariadb-server-main/sql/sql_parse.cc:1902
#15 0x0000000000ba3d9e in do_handle_one_connection (connect=0x2bc16ff8, put_in_cache=true) at /home/dan/repos/mariadb-server-main/sql/sql_connect.cc:1415
create_user = true
thr_create_utime = 58881449345
thd = 0x7fd46c000dc8
#16 0x0000000000ba3b2c in handle_one_connection (arg=0x2bc16ff8) at /home/dan/repos/mariadb-server-main/sql/sql_connect.cc:1327
connect = 0x2bc16ff8
#17 0x000000000112620c in pfs_spawn_thread (arg=0x2bc33068) at /home/dan/repos/mariadb-server-main/storage/perfschema/pfs.cc:2198
Aside - even with k3s - use multiple containers - one for db and one for app and let the mariadb container handle its intialization (and create database via MARIADB_DATABASE) like:
apiVersion: v1
kind: Namespace
metadata:
name: myapp
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mariadb-deployment
namespace: myapp
spec:
replicas: 1
selector:
matchLabels:
app: mariadb
template:
metadata:
labels:
app: mariadb
spec:
containers:
- name: mariadb
image: mariadb:latest
env:
- name: MARIADB_ROOT_PASSWORD
value: "rootpassword"
- name: MARIADB_DATABASE
value: "mydatabase"
ports:
- containerPort: 3306
volumeMounts:
- name: mariadb-data
mountPath: /var/lib/mysql
readinessProbe:
exec:
command:
- /usr/local/bin/healthcheck.sh
- --connect
- --innodb_initialized
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 5
livenessProbe:
exec:
command:
- /usr/local/bin/healthcheck.sh
- --connect
- --innodb_initialized
initialDelaySeconds: 20
periodSeconds: 10
timeoutSeconds: 5
volumes:
- name: mariadb-data
persistentVolumeClaim:
claimName: mariadb-pvc
---
apiVersion: v1
kind: Service
metadata:
name: mariadb
namespace: myapp
spec:
selector:
app: mariadb
ports:
- protocol: TCP
port: 3306
targetPort: 3306
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: python-app-deployment
namespace: myapp
spec:
replicas: 1
selector:
matchLabels:
app: python-app
template:
metadata:
labels:
app: python-app
spec:
containers:
- name: python-app
image: my-python-app:latest
env:
- name: DB_HOST
value: mariadb.myapp.svc.cluster.local
- name: DB_PORT
value: "3306"
- name: DB_USER
value: "root"
- name: DB_PASSWORD
value: "rootpassword"
ports:
- containerPort: 5000
readinessProbe:
httpGet:
path: /health
port: 5000
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 3
command: ["python", "app.py"]
initContainers:
- name: wait-for-mariadb
image: busybox
- sh
- -c
- "until nc -z mariadb.myapp.svc.cluster.local 3306; do echo 'Waiting for MariaDB...'; sleep 2; done;"
I tried on this "SELECT * FROM sometable WHERE something=1 AND (SELECT 1 FROM information_schema.users) = 1" without preproduction, so it looks like this is part of the query and the rest of it is significant enough to cause the bug trigger. Do you have the rest of the query?