Bug #81109 mysqld crash on windows 2012 server when GR cluster have another node in Linux
Submitted: 17 Apr 2016 4:30 Modified: 17 Apr 2016 5:10
Reporter: Sudipta Sahoo Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Group Replication Severity:S2 (Serious)
Version:5.7.13 OS:Windows (Windows Server 2012R)
Assigned to: CPU Architecture:Any
Tags: SYSQA, sysqa_crash, sysqa_GR

[17 Apr 2016 4:30] Sudipta Sahoo
Description:
Group Replication cluster setup failed when node1 run on Windows server 2012R and another node trying to connect to the cluster from Linux. Mysqld error shows -[MYSQL_GCS_DEBUG] [XCOM_BINDING_DEBUG] ::xcom_receive_global_view():: State Exchange started.
[MYSQL_GCS_DEBUG] [XCOM_BINDING_DEBUG] 11:17:10 UTC - mysqld got exception 0xe06d7363 ;
This issue not observed when running on windows7 box. Issue can be reproduce with simple steps - start mysqld on windows2012R, configure and start the GR. Then start another node on Linux, configure GR and try to add this node2 to the GR cluster. This will crash the mysqld running on Windows 2012R. If we configure 2 node on windows 2012 R server and add them the GR cluster, no crash.

Error details -

[MYSQL_GCS_DEBUG] [XCOM_BINDING_DEBUG] ::send_binding_message():: Pipelining message with payload length 106
[MYSQL_GCS_DEBUG] [XCOM_BINDING_DEBUG] ::send_binding_message():: Sending message with payload length 106
[MYSQL_GCS_DEBUG] [XCOM_BINDING_DEBUG] ::xcom_receive_global_view():: State Exchange started.
[MYSQL_GCS_DEBUG] [XCOM_BINDING_DEBUG] 11:17:10 UTC - mysqld got exception 0xe06d7363 ;
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=2
max_threads=151
thread_count=4
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68010 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
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...
7ff82e718a5c    KERNELBASE.dll!RaiseException()
7ff81197426b    group_replication.dll!???
7ff8119736d0    group_replication.dll!???
7ff8118c0474    group_replication.dll!???
7ff8118fe1a1    group_replication.dll!???
7ff8118fe1eb    group_replication.dll!???
7ff81190bc33    group_replication.dll!???
7ff81190be2b    group_replication.dll!???
7ff81190e03b    group_replication.dll!???
7ff8119767a7    group_replication.dll!???
7ff8119769f2    group_replication.dll!???
7ff830d813d2    KERNEL32.DLL!BaseThreadInitThunk()
7ff8312c54e4    ntdll.dll!RtlUserThreadStart()
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Call stack:
group_replication.dll!00007ff8119736d2() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for group_replication.dll]	
 	group_replication.dll!00007ff8118b0000() 	
 	0000080000000000()	
 	0000080000000000()	
 	group_replication.dll!00007ff8118c7025() 	
 	group_replication.dll!00007ff8118c0474() 	
 	group_replication.dll!00007ff8118fe1a1() 	
 	group_replication.dll!00007ff8118fe1eb() 	
 	group_replication.dll!00007ff81190bc33() 	
 	group_replication.dll!00007ff81190be2b() 	
 	group_replication.dll!00007ff81190e03b() 	
 	group_replication.dll!00007ff8119767a7() 	
 	group_replication.dll!00007ff8119769f2() 	
 	kernel32.dll!00007ff830d813d2() 	
 	ntdll.dll!00007ff8312c54e4() 	

How to repeat:
Windows server 2012R(vitro60)

On Windows:
(vitro60)

E://Sudipta//mysql-adv-GR//bin//mysqld --no-defaults --user=root --initialize-insecure --explicit_defaults_for_timestamp --basedir=E://Sudipta//mysql-adv-GR --datadir=E:\\Sudipta\\data

E://Sudipta//mysql-adv-GR//bin//mysqld --no-defaults --basedir=E://Sudipta//mysql-adv-GR --datadir=E:\\Sudipta\\data -P13001 --socket=E://Sudipta//mysqld1.sock --log-bin=master-bin --server-id=1 --gtid-mode=on --enforce-gtid-consistency --log-slave-updates --binlog-checksum=NONE --binlog-format=row  --master-info-repository=TABLE --relay-log-info-repository=TABLE --transaction-write-set-extraction=MURMUR32 --log-error --general-log --plugin-dir=lib\\plugin --plugin-load=group_replication.dll --group_replication_group_name="8a94f357-aab4-11df-86ab-c80aa9429562"  --core-file

##connect to the mysqld and run below commands(specific to vitro08, change host name accordingly - vitro60 and viking32(linux))
mysql --no-defaults -P13001 -uroot

SET GLOBAL group_replication_local_address='vitro60:10401';
SET GLOBAL group_replication_peer_addresses='vitro60:10401,viking32:10402,viking32:10403,viking32:10404';

CREATE USER 'rpl_user'@'%' IDENTIFIED BY 'rpl_pass';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';

SET GLOBAL group_replication_bootstrap_group= 1;
SET GLOBAL group_replication_start_on_boot = ON;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' FOR CHANNEL 'group_replication_recovery';
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group= 0;

Then start another node on a Linux(OEL7) box.

./bin/mysqld --no-defaults --user=root --initialize-insecure --explicit_defaults_for_timestamp --basedir=. --datadir=data02   

./bin/mysqld --no-defaults --basedir=. --datadir=data02 -P 13002 \
--socket=/tmp/mysqld2.sock --log-bin=master-bin --server-id=2  \
--gtid-mode=on --enforce-gtid-consistency --log-slave-updates  \
--binlog-checksum=NONE --binlog-format=row  \
--master-info-repository=TABLE --relay-log-info-repository=TABLE \
--transaction-write-set-extraction=MURMUR32 --log-error --general-log  \
--plugin-dir=lib/plugin --plugin-load=group_replication.so \
--group_replication_group_name="8a94f357-aab4-11df-86ab-c80aa9429562" &

$MYSQL_HOME/bin/mysql -uroot -h 127.0.0.1 -P 13002  -e "SET GLOBAL group_replication_local_address='viking32:10402';"
$MYSQL_HOME/bin/mysql -uroot -h 127.0.0.1 -P 13002  -e "SET GLOBAL group_replication_peer_addresses='vitro60:10401,viking32:10402,viking32:10403';"
$MYSQL_HOME/bin/mysql -uroot -h 127.0.0.1 -P 13002  -e  "CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' FOR CHANNEL 'group_replication_recovery';"
$MYSQL_HOME/bin/mysql -uroot -h 127.0.0.1 -P 13002  -e "START GROUP_REPLICATION;"

Suggested fix:
mysqld server should not crash on windows2012R