| Bug #82806 | MySQL server crashes when trying to persist enforce_gtid_consistency | ||
|---|---|---|---|
| Submitted: | 31 Aug 2016 5:22 | Modified: | 16 Nov 2016 6:00 |
| Reporter: | Giuseppe Maxia (OCA) | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server: Options | Severity: | S1 (Critical) |
| Version: | 8.0.0, 8.0.1 | OS: | Ubuntu |
| Assigned to: | CPU Architecture: | Any | |
[31 Aug 2016 5:49]
MySQL Verification Team
Hello Giuseppe, Thank you for the report. Verified as described with the 8.0 daily build. Thanks, Umesh
[31 Aug 2016 5:57]
MySQL Verification Team
-- 8.0.1
rm -rf 82806
bin/mysqld --initialize-insecure --basedir=/export/umesh/server/binaries/Trunk/mysql-advanced-8.0 --datadir=/export/umesh/server/binaries/Trunk/mysql-advanced-8.0/82806 -v
bin/mysqld --no-defaults --basedir=/export/umesh/server/binaries/Trunk/mysql-advanced-8.0 --datadir=/export/umesh/server/binaries/Trunk/mysql-advanced-8.0/82806 --core-file --socket=/tmp/mysql_ushastry.sock --port=3306 --log-error=/export/umesh/server/binaries/Trunk/mysql-advanced-8.0/82806/log.err 2>&1 &
[umshastr@hod03]/export/umesh/server/binaries/Trunk/mysql-advanced-8.0: cat docs/INFO_SRC
commit: 7202a46dccad871ac77ce6d4fd67183e6902134a
date: 2016-08-30 17:54:58 +0300
build-date: 2016-08-30 17:01:28 +0200
short: 7202a46
branch: mysql-trunk
MySQL source 8.0.1
(gdb) bt
#0 0x00007f418abe4771 in pthread_kill () from /lib64/libpthread.so.0
#1 0x0000000000babdbd in handle_fatal_signal (sig=11) at /export/home/pb2/build/sb_0-20238057-1472571207.78/mysqlcom-pro-8.0.1-dmr/sql/signal_handler.cc:219
#2 <signal handler called>
#3 0x00007f41896db38a in __strcmp_sse42 () from /lib64/libc.so.6
#4 0x0000000000915dd1 in sys_var::is_default (this=<optimized out>, thd=<optimized out>, var=<optimized out>)
at /export/home/pb2/build/sb_0-20238057-1472571207.78/mysqlcom-pro-8.0.1-dmr/sql/set_var.cc:338
#5 0x0000000000908d67 in Persisted_variables_cache::set_variable (this=this@entry=0x27359a0 <persisted_variables_cache>, thd=thd@entry=0x7f4130000b50, setvar=setvar@entry=0x7f41300077e8)
at /export/home/pb2/build/sb_0-20238057-1472571207.78/mysqlcom-pro-8.0.1-dmr/sql/persisted_variable.cc:120
#6 0x00000000009176d8 in sql_set_variables (thd=thd@entry=0x7f4130000b50, var_list=var_list@entry=0x7f4130003008, opened=opened@entry=true)
at /export/home/pb2/build/sb_0-20238057-1472571207.78/mysqlcom-pro-8.0.1-dmr/sql/set_var.cc:744
#7 0x000000000097e10c in mysql_execute_command (thd=thd@entry=0x7f4130000b50, first_level=first_level@entry=true)
at /export/home/pb2/build/sb_0-20238057-1472571207.78/mysqlcom-pro-8.0.1-dmr/sql/sql_parse.cc:3391
#8 0x0000000000981f75 in mysql_parse (thd=thd@entry=0x7f4130000b50, parser_state=parser_state@entry=0x7f417c0f0750)
at /export/home/pb2/build/sb_0-20238057-1472571207.78/mysqlcom-pro-8.0.1-dmr/sql/sql_parse.cc:5233
#9 0x0000000000982808 in dispatch_command (thd=thd@entry=0x7f4130000b50, com_data=com_data@entry=0x7f417c0f0e10, command=COM_QUERY)
at /export/home/pb2/build/sb_0-20238057-1472571207.78/mysqlcom-pro-8.0.1-dmr/sql/sql_parse.cc:1481
#10 0x0000000000983f83 in do_command (thd=thd@entry=0x7f4130000b50) at /export/home/pb2/build/sb_0-20238057-1472571207.78/mysqlcom-pro-8.0.1-dmr/sql/sql_parse.cc:1043
#11 0x0000000000ba3170 in handle_connection (arg=arg@entry=0x4774e20)
at /export/home/pb2/build/sb_0-20238057-1472571207.78/mysqlcom-pro-8.0.1-dmr/sql/conn_handler/connection_handler_per_thread.cc:301
#12 0x0000000001503f84 in pfs_spawn_thread (arg=0x47da1d0) at /export/home/pb2/build/sb_0-20238057-1472571207.78/mysqlcom-pro-8.0.1-dmr/storage/perfschema/pfs.cc:2282
#13 0x00007f418abdfdf5 in start_thread () from /lib64/libpthread.so.0
#14 0x00007f418969f60d in clone () from /lib64/libc.so.6
(gdb)
[31 Aug 2016 7:22]
MySQL Verification Team
Another few crashers: set persist innodb_tmpdir ='/tmp'; set persist character_set_results =null; set persist session_track_system_variables =null; set persist innodb_monitor_enable =0x4425; IMHO what needs to happen is somebody test each and every variable with persist.
[31 Aug 2016 7:28]
MySQL Verification Team
Crashes when setting to default: set persist enforce_gtid_consistency:=default; set persist innodb_ft_aux_table:=default; set persist innodb_ft_server_stopword_table:=default; set persist innodb_ft_user_stopword_table:=default; set persist innodb_monitor_disable:=default; set persist innodb_monitor_enable:=default; set persist innodb_monitor_reset:=default; set persist innodb_monitor_reset_all:=default; set persist innodb_tmpdir:=default;
[19 Sep 2016 8:39]
Erlend Dahl
Duplicate of Bug#82726 SET PERSIST writes default values to mysqld-auto.conf rather than removing them
[19 Sep 2016 10:34]
Giuseppe Maxia
How can this be a duplicate of Bug#82726 ? This bug reports a crash. No such thing happens in the other bug.
[16 Nov 2016 6:00]
MySQL Verification Team
Hi Giuseppe, Please be informed that development has confirmed internally that this bug is no longer reproducible after the fix to Bug #82726(bug#24522064), which also fixed the server crash reported in this bug report. Thanks, Umesh
Description: Running the following command, the server crashes: mysql [localhost] {msandbox} ((none)) > set persist enforce_gtid_consistency=on; ERROR 2013 (HY000): Lost connection to MySQL server during query From the log: Version: '8.0.0-dmr' socket: '/tmp/mysql_sandbox8000.sock' port: 8000 MySQL Community Server (GPL) 2016-08-30T16:25:29.045588Z 6 [Note] Changed ENFORCE_GTID_CONSISTENCY from OFF to ON. 16:25:29 UTC - 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. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=1 max_threads=151 thread_count=1 connection_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68169 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7f8bcc7dbe30 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 = 7f8bb825be80 thread_stack 0x40000 /home/gmax/opt/mysql/full_8.0.0/bin/mysqld(my_print_stacktrace+0x2e) [0x118b49e] /home/gmax/opt/mysql/full_8.0.0/bin/mysqld(handle_fatal_signal+0x481) [0xb74281] /lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0) [0x7f8bdbbef3d0] /lib/x86_64-linux-gnu/libc.so.6(+0x9eb5e) [0x7f8bda5c1b5e] /home/gmax/opt/mysql/full_8.0.0/bin/mysqld(sys_var::is_default(THD*, set_var*)+0x71) [0x8d7b71] /home/gmax/opt/mysql/full_8.0.0/bin/mysqld(Persisted_variables_cache::set_variable(THD*, set_var*)+0x47) [0x8ca5f7] /home/gmax/opt/mysql/full_8.0.0/bin/mysqld(sql_set_variables(THD*, List<set_var_base>*, bool)+0x158) [0x8d9688] /home/gmax/opt/mysql/full_8.0.0/bin/mysqld(mysql_execute_command(THD*, bool)+0x1e84) [0x925494] /home/gmax/opt/mysql/full_8.0.0/bin/mysqld(mysql_parse(THD*, Parser_state*)+0x3fd) [0x927aad] /home/gmax/opt/mysql/full_8.0.0/bin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x8b4) [0x9283d4] /home/gmax/opt/mysql/full_8.0.0/bin/mysqld(do_command(THD*)+0x22e) [0x929b6e] /home/gmax/opt/mysql/full_8.0.0/bin/mysqld() [0xb6b620] /home/gmax/opt/mysql/full_8.0.0/bin/mysqld() [0x11ab424] /lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa) [0x7f8bdbbe56fa] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f8bda629b5d] How to repeat: set persist enforce_gtid_consistency=on;