Bug #78263 GR+XA: ASSERT `M_TRANSACTION_CTX.M_SIDNO == 0 && M_TRANSACTION_CTX.M_GNO == 0'
Submitted: 28 Aug 2015 15:30 Modified: 10 Sep 2015 13:57
Reporter: Nuno Carvalho Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.7.6 OS:Any
Assigned to: CPU Architecture:Any

[28 Aug 2015 15:30] Nuno Carvalho
Description:
XA transactions are hitting a assert condition on XA COMMIT, this
is happening because despite XA transaction is composed by two 
transactions: XA PREPARE; XA COMMIT/ROLLBACK; for engines and binary
log. The internal transaction state is not reset between PREPARE and 
COMMIT/ROLLBACK, what was causing the assert on Rpl_transaction_ctx
to be triggered.

How to repeat:
Steps to repro:
===============
Run command: ./mtr group_replication_xa_crash.test --suite=group_replication
--debug-server --mysqld=--enforce-gtid-consistency
--mysqld=--log-slave-updates --mysqld=--gtid-mode=on
--mysqld=--binlog-format=row
--mysqld=--transaction-write-set-extraction=MURMUR32
--mysqld=--binlog-checksum=NONE --mysqld=--master-info-repository=TABLE
--mysqld=--relay_log_info_repository=TABLE
--mysqld=--plugin-load=group_replication.so
--mysqld=--plugin-dir=<PLUGIN_PATH> --mysqld=--relay-log-recovery=on
--mysqld=--group-replication-group-name='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'

Where,
$ cat group_replication_xa_crash.test
--source include/have_group_replication_plugin.inc
--let $group_replication_group_name= aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

--echo
--let $rpl_connection_name= server1
--source include/rpl_connection.inc
--echo [ON SERVER1]
START GROUP_REPLICATION;
CREATE TABLE tab1 (a INT PRIMARY KEY);
--echo
XA START 'xatest';
INSERT INTO tab1 VALUES (1);
XA END 'xatest';
XA PREPARE 'xatest';
--echo ==== CRASH HERE ====
XA COMMIT 'xatest';
SHOW BINLOG EVENTS;

--die "OK TO STOP HERE"
[10 Sep 2015 13:57] Jon Stephens
Documented fix in the 5.7.9 and 5.8.0 changelogs, as follows:

    XA transactions could cause an assert condition on XA COMMIT;
    this was happening because the internal transaction state was
    not reset between XA PREPARE and XA COMMIT or XA ROLLBACK, due
    to the fact that these operations constitute separate
    transactions under XA. In addition, XA ROLLBACK was not properly
    handled in some cases.

Closed.