mysqld XA crash in replication slave

Bug #1024058 reported by rich prohaska
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MariaDB
New
Critical
Sergei Golubchik

Bug Description

We found a simple XA transaction that crashes MySQL 5.5 replication. This simple transaction merely inserts into InnoDB and TokuDB tables. The bug was caused by a flaw in the logging code exposed by the transaction’s use of two XA storage engines (TokuDB and InnoDB) and was fixed in the TokuDB 6.0.1 release.

Here are some details. Suppose that a database contains the following tables.
create table t1 (a int) engine=InnoDB
create table t2 (a int) engine=TokuDB

The following transaction
begin
insert into t1 values (1)
insert into t2 values (2)
commit
causes the replication slave to crash.

The crash occurs when mysqld tries to dereference a NULL pointer.

#4 0x000000000088e203 in MYSQL_BIN_LOG::log_and_order (this=0x14b8640, thd=0x7f7758000af0, xid=161, all=true, need_prepare_ordered=false, need_commit_ordered=true) at /home/mariadb-5.5.25/sql/log.cc:7491
7491 cache_mngr->using_xa= TRUE;
(gdb) p cache_mngr
$1 = (binlog_cache_mngr *) 0x0

the bug is fixed on lp:~prohaska7/5.5-xa-rpl-crash-fix

also, see mariadb developers email chain.

Elena Stepanova (elenst)
Changed in maria:
milestone: none → 5.5
importance: Undecided → Critical
assignee: nobody → Sergei (sergii)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.