[MDEV-443] Galera: Server crashes on flushing tables for SST if started with character_set_server utf16 or utf32 or ucs2, and with wsrep_sst_method=rsync Created: 2012-08-08  Updated: 2013-12-04  Resolved: 2013-12-04

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.5.34-galera

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates

 Description   

 
120808 22:26:23 [Note] WSREP: Running: 'wsrep_sst_rsync 'donor' '192.168.1.5:4444/rsync_sst' 'galera:galera' '/home/elenst/galera-5.5/data1/' '' '871ddeac-e186-11e1-0800-3ba72ed0465d' '0' '0''
120808 22:26:23 [Note] WSREP: sst_donor_thread signaled with 0
120808 22:26:23 [Note] WSREP: Flushing tables for SST...
120808 22:26:23 [ERROR] mysqld got signal 11 ;

#3  <signal handler called>
#4  0x000000000060544f in lex_one_token (arg=0x7fd2db252b70, yythd=0x29f9640) at sql/sql_lex.cc:1036
#5  0x000000000060526a in MYSQLlex (arg=0x7fd2db252b70, yythd=0x29f9640) at sql/sql_lex.cc:975
#6  0x0000000000777a33 in MYSQLparse (yythd=0x29f9640) at sql/sql_yacc.cc:18129
#7  0x0000000000626632 in parse_sql (thd=0x29f9640, parser_state=0x7fd2db254740, creation_ctx=0x0)
    at sql/sql_parse.cc:8642
#8  0x000000000062029d in mysql_parse (thd=0x29f9640, rawbuf=0xd7e683 "FLUSH TABLES WITH READ LOCK", length=27, 
    parser_state=0x7fd2db254740) at sql/sql_parse.cc:6163
#9  0x0000000000771cf5 in run_sql_command (thd=0x29f9640, query=0xd7e683 "FLUSH TABLES WITH READ LOCK")
    at sql/wsrep_sst.cc:685
#10 0x0000000000771ea3 in sst_flush_tables (thd=0x29f9640) at sql/wsrep_sst.cc:705
#11 0x000000000077269d in sst_donor_thread (a=0x7fd30171a190) at sql/wsrep_sst.cc:808
#12 0x00007fd30dce5efc in start_thread (arg=0x7fd2db255700) at pthread_create.c:304
#13 0x00007fd30d49559d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0xd7e683): FLUSH TABLES WITH READ LOCK
Connection ID (thread ID): 0
Status: NOT_KILLED

Server command lines:

/home/elenst/galera-5.5/sql/mysqld --no-defaults --datadir=/home/elenst/galera-5.5/data1 --wsrep_provider=/home/elenst/galera-23.2.1-src/libgalera_smm.so --wsrep_sst_method=mysqldump --core --binlog-format=row --log-bin=master-bin --default-storage-engine=InnoDB --innodb_autoinc_lock_mode=2 --innodb_locks_unsafe_for_binlog=1 --innodb_flush_log_at_trx_commit=0 --innodb_doublewrite=0 --log-error=log.err --wsrep_sst_auth=galera:galera --basedir=/home/elenst/galera-5.5/ --port=8306 --loose-lc-messages-dir=/home/elenst/galera-5.5/sql/share --loose-language=/home/elenst/galera-5.5/sql/share/english --socket=/tmp/elenst-galera-1.sock --wsrep_cluster_address=gcomm:// --character-set-server=utf16 --tmpdir=/home/elenst/galera-5.5/data1/tmp --wsrep_slave_threads=4 --general-log=1
/home/elenst/galera-5.5/sql/mysqld --no-defaults --datadir=/home/elenst/galera-5.5/data2 --wsrep_provider=/home/elenst/galera-23.2.1-src/libgalera_smm.so --wsrep_sst_method=mysqldump --core --binlog-format=row --log-bin=master-bin --default-storage-engine=InnoDB --innodb_autoinc_lock_mode=2 --innodb_locks_unsafe_for_binlog=1 --innodb_flush_log_at_trx_commit=0 --innodb_doublewrite=0 --log-error=log.err --wsrep_sst_auth=galera:galera --basedir=/home/elenst/galera-5.5/ --port=8307 --loose-lc-messages-dir=/home/elenst/galera-5.5/sql/share --loose-language=/home/elenst/galera-5.5/sql/share/english --socket=/tmp/elenst-galera-2.sock --wsrep_cluster_address=gcomm://127.0.0.1:4567?gmcast.listen_addr=tcp://127.0.0.1:4566 --character-set-server=utf16 --tmpdir=/home/elenst/galera-5.5/data2/tmp --wsrep_slave_threads=4 --general-log=1

Executing FLUSH TABLES WITH READ LOCK on an already running server (e.g. if it was started with wsrep_sst_method=mysqldump) does not cause the crash.

bzr version-info (maria-5.5-galera)

revision-id: jani@work-20120723081559-lcsbsui4dl9vsfbu
date: 2012-07-23 11:15:59 +0300
build-date: 2012-08-08 18:36:09 +0400
revno: 3342

Build options: -DCMAKE_BUILD_TYPE=Debug -DWITH_WSREP=ON -DWITH_INNODB_DISALLOW_WRITES=1

galera-23.2.1

How to reproduce:

- start a new node with --wsrep_sst_method=rsync and --character_set_server=utf16;
- wait till it started;
- start another node with the same parameters, pointing at the first one;
- check the status of the first node (it crashes)



 Comments   
Comment by Elena Stepanova [ 2012-08-09 ]

See http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_character_set_client about ucs2, utf16, and utf32 not allowed to "be used as a client character set, which means that they also do not work for SET NAMES or SET CHARACTER SET." – it might be somehow related.

Comment by Elena Stepanova [ 2012-08-12 ]

Switched to Minor temporarily, as I think it can be tolerated for the first alpha release.

Comment by Jan Lindström (Inactive) [ 2013-12-04 ]

wsrep_sst.cc directly sends a SQL to the parser. Maybe the best way is to temporally set such a character set that is supported by the parser if current character set is part of the unsupported ones.

Comment by Jan Lindström (Inactive) [ 2013-12-04 ]

In SST Galera directly calls parser using current client character
set. Similarly in BF Galera uses client character set to apply. However,
there are character sets that are not currently supported by the parser.

Fix: If currenct client character set is one of those that is not supported
by the parser, temporally set character set to latin1 before we enter
parser and restore it after we have parsed.

Generated at Thu Feb 08 06:28:47 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.