Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL)
-
None
Description
Not sure if this is intentional? I don't think it's an improvement ...!
MariaDB [(none)]> SHOW DATABASES;
|
+--------------------+
|
| Database |
|
+--------------------+
|
| information_schema |
|
| mysql |
|
| performance_schema |
|
| sys |
|
+--------------------+
|
4 rows in set (0.001 sec)
|
|
|
MariaDB [(none)]> SHOW VARIABLES LIKE 'version%';
|
+-------------------------+---------------------------------------------------------+
|
| Variable_name | Value |
|
+-------------------------+---------------------------------------------------------+
|
| version | 10.8.0-MariaDB-ea9489536911b083c5e28b15c071cf6931247b7e |
|
| version_comment | mariadb.org binary distribution |
|
| version_compile_machine | x86_64 |
|
| version_compile_os | debian-linux-gnu |
|
| version_malloc_library | system |
|
| version_source_revision | ea9489536911b083c5e28b15c071cf6931247b7e |
|
| version_ssl_library | OpenSSL 1.1.1f 31 Mar 2020 |
|
+-------------------------+---------------------------------------------------------+
|
7 rows in set (0.002 sec)
|
Note: If using the mariadb 10.8 CLI the columns are left-aligned. The above is using mariadb CLI from 10.5.
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
Activity
I can't seem to find 10.5.14 on the mariadb.org downloads page yet.
The effect is visible for me in the 10.5.10 and 10.5.13 clients. (Admittedly, these are fc34 packages running on fc35.)
I have also just tested with the 10.5.13 and 10.6.5 clients that are included in the binary tar.gz downloads on mariadb.org. The effect is exhibited in the 10.5.13 client, but not in the 10.6.5 client.
|
|
MariaDB [(none)]> show tables from mysql;
|
+---------------------------+
|
| Tables_in_mysql |
|
+---------------------------+
|
| column_stats |
|
| columns_priv |
|
| db |
|
...
|
+---------------------------+
|
31 rows in set (0.001 sec)
|
|
|
MariaDB [(none)]> \s
|
--------------
|
./mariadb Ver 15.1 Distrib 10.5.13-MariaDB, for Linux (x86_64) using readline 5.1
|
...
|
Server version: 10.8.0-MariaDB-ea9489536911b083c5e28b15c071cf6931247b7e mariadb.org binary distribution
|
...
|
Thanks for the report!
The problem is not specific to 10.8.0.
The reason why it happens with the mariadb-devel docker container is that it contains a config file which sets the version option.
The failure occurs when
- a 10.5+ server is started with --version=<something> option. The value doesn't need to be anyhow weird, even the default value from the same server will do, as long as it's provided explicitly;
- a 10.2-10.5 client connects to this server.
Thus, the easiest way to reproduce is on 10.5, as it doesn't require cross-versioning:
|
10.5 be20b3b0 |
$ bin/mysqld --version
|
bin/mysqld Ver 10.5.14-MariaDB-debug for Linux on x86_64 (Source distribution)
|
|
|
$ bin/mysqld --no-defaults --basedir=`pwd` --datadir=`pwd`/data --socket=/tmp/my.sock --version=10.5.14-MariaDB-debug &
|
...
|
2021-12-24 17:03:40 0 [Note] bin/mysqld: ready for connections.
|
Version: '10.5.14-MariaDB-debug' as '10.5.14-MariaDB-debug' socket: '/tmp/my.sock' port: 3306 Source distribution
|
|
|
$ bin/mysql --socket=/tmp/my.sock -e "show databases"
|
+--------------------+
|
| Database |
|
+--------------------+
|
| information_schema |
|
| mysql |
|
| performance_schema |
|
| test |
|
| tmp |
|
+--------------------+
|
10.2-10.5 clients are affected starting from this libmariadb update in 10.2:
commit 2c8fa28f40315c237896980ea5fcc1801f7ba140
|
Author: Marko Mäkelä
|
Date: Fri Mar 13 07:21:40 2020 +0200
|
|
|
Update libmariadb
|
|
This fixes GCC 10.0.1 -Wstringop-truncation and some typos.
|
|
|
diff --git a/libmariadb b/libmariadb
|
index 8e9c3116105..f9a50468cd7 160000
|
--- a/libmariadb
|
+++ b/libmariadb
|
@@ -1 +1 @@
|
-Subproject commit 8e9c3116105d9a998a60991b7f4ba910d454d4b1
|
+Subproject commit f9a50468cd7f35f2e22dc874c185e34b78766a2e
|
I assume 10.5+ servers started being affected at the same time, at least 10.5.0 works okay even with an affected client, and 10.5.5 shows the problem (the commit above went to 10.5.2).
I didn't bisect libmariadb.
There are other failures which are likely to be related. For example, on the same 10.5 above, if instead of show databases we run a select * from information_schema.system_variables, it crashes:
#3 <signal handler called>
|
#4 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
|
#5 0x0000000000788d58 in fill_sysvars (thd=0x7fcb14000db8, tables=0x7fcb140164f0, cond=0x0) at /data/src/10.5/sql/set_var.cc:1259
|
#6 0x00000000009c27f5 in get_schema_tables_result (join=0x7fcb14017c98, executed_place=PROCESSED_BY_JOIN_EXEC) at /data/src/10.5/sql/sql_show.cc:8819
|
#7 0x0000000000961568 in JOIN::exec_inner (this=0x7fcb14017c98) at /data/src/10.5/sql/sql_select.cc:4473
|
#8 0x000000000096073e in JOIN::exec (this=0x7fcb14017c98) at /data/src/10.5/sql/sql_select.cc:4296
|
#9 0x0000000000938c8d in mysql_select (thd=0x7fcb14000db8, tables=0x7fcb140164f0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2684619520, result=0x7fcb14017c70, unit=0x7fcb14004f60, select_lex=0x7fcb14015ea8) at /data/src/10.5/sql/sql_select.cc:4773
|
#10 0x0000000000938494 in handle_select (thd=0x7fcb14000db8, lex=0x7fcb14004e98, result=0x7fcb14017c70, setup_tables_done_option=0) at /data/src/10.5/sql/sql_select.cc:444
|
#11 0x00000000008f16d2 in execute_sqlcom_select (thd=0x7fcb14000db8, all_tables=0x7fcb140164f0) at /data/src/10.5/sql/sql_parse.cc:6314
|
#12 0x00000000008e4a8f in mysql_execute_command (thd=0x7fcb14000db8) at /data/src/10.5/sql/sql_parse.cc:4005
|
#13 0x00000000008db59f in mysql_parse (thd=0x7fcb14000db8, rawbuf=0x7fcb14015de8 "select * from information_schema.system_variables", length=49, parser_state=0x7fcb60243cd8, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8100
|
#14 0x00000000008d795e in dispatch_command (command=COM_QUERY, thd=0x7fcb14000db8, packet=0x7fcb1400b4a9 "select * from information_schema.system_variables", packet_length=49, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1891
|
#15 0x00000000008dc560 in do_command (thd=0x7fcb14000db8) at /data/src/10.5/sql/sql_parse.cc:1370
|
#16 0x0000000000ab9e70 in do_handle_one_connection (connect=0x471fb88, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1418
|
#17 0x0000000000ab9afa in handle_one_connection (arg=0x471d158) at /data/src/10.5/sql/sql_connect.cc:1312
|
#18 0x000000000107740f in pfs_spawn_thread (arg=0x471d238) at /data/src/10.5/storage/perfschema/pfs.cc:2201
|
#19 0x00007fcb62985609 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#20 0x00007fcb626a7293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
Note: I've set the affected versions to all RC+, but as described above, in some versions it's the server and in others the client. I'm not yet sure which side, if any, requires a fix (maybe it will turn out to be a fault of CONC alone), so I expect the versions to be adjusted later as needed
The crash for due to a different reason, but I've fixed it too, under the same number.
simply running 10.5 client with a 10.8 server does not exhibit this effect:
MariaDB [test]> show tables from mysql;+---------------------------+| Tables_in_mysql |+---------------------------+| columns_priv || db |...+---------------------------+16 rows in set (0.002 sec)MariaDB [test]> \s--------------client/mysql Ver 15.1 Distrib 10.5.14-MariaDB, for Linux (x86_64) using readline 5.1...Server version: 10.8.0-MariaDB-debug Source distribution...