Bug #59986 Assert in Diagnostics_area::set_ok_status() for XA COMMIT

Submitted: 7 Feb 2011 14:29 Modified: 6 Apr 2011 1:45
Reporter: Jon Olav Hauglid Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Locking Severity:S3 (Non-critical)
Version:5.5, trunk OS:Any
Assigned to: Jon Olav Hauglid CPU Architecture:Any

[7 Feb 2011 14:29] Jon Olav Hauglid
Description:
This bug is split from Bug#59936, reported as assertion [4] there.

#6  0x00007fcb2eaf8a71 in __assert_fail (assertion=0xcef9c5 "! is_set()", 
    file=<value optimized out>, line=358, 
    function=0xceff60 "void Diagnostics_area::set_ok_status(THD*, ulonglong, ulonglong, const char*)") at assert.c:81
#7  0x00000000006be0c8 in Diagnostics_area::set_ok_status (this=0x7fcb200212f8, thd=
    0x7fcb2001e440, affected_rows_arg=0, last_insert_id_arg=0, message_arg=0x0)
    at /export/home/x/mysql-trunk-bug59936/sql/sql_error.cc:358
#8  0x000000000067eec8 in my_ok (thd=0x7fcb2001e440, affected_rows=0, id=0, message=0x0)
    at /export/home/x/mysql-trunk-bug59936/sql/sql_class.h:2986
#9  0x00000000006e87a7 in mysql_execute_command (thd=0x7fcb2001e440)
    at /export/home/x/mysql-trunk-bug59936/sql/sql_parse.cc:4241
#10 0x00000000006eb92c in mysql_parse (thd=0x7fcb2001e440, 
    rawbuf=0x34a3dd0 "xa commit 'xid1' one phase", length=26, parser_state=0x7fcb2852d030)
    at /export/home/x/mysql-trunk-bug59936/sql/sql_parse.cc:5549

(gdb) p *thd->stmt_da
$1 = {is_sent = false, can_overwrite_status = false, 
  m_message = "XA_RBDEADLOCK: Transaction branch was rolled back: deadlock was detected\000 the  NON-EXISTING state\000ates: 0  Warnings: 0\000\060\000e a transaction\000ransaction is in the  NON-EXISTING state\000ates: 0  Warnings: 0\000i"..., m_sql_errno = 1614, m_sqlstate = "XA102", 
  m_affected_rows = 0, m_last_insert_id = 0, m_statement_warn_count = 0, 
  m_status = Diagnostics_area::DA_ERROR}

How to repeat:
See Bug#59936
[7 Feb 2011 16:57] Jon Olav Hauglid
MTR test case:

CREATE TABLE t1(a INT, b INT, PRIMARY KEY(a)) engine=InnoDB;
INSERT INTO t1 VALUES (1, 1), (2, 2);

connect (con1, localhost, root);
XA START 'a';
UPDATE t1 SET b= 3 WHERE a=1;

connection default;
XA START 'b';
UPDATE t1 SET b=4 WHERE a=2;
--send UPDATE t1 SET b=5 WHERE a=1

connection con1;
--sleep 1
--error ER_LOCK_DEADLOCK
UPDATE t1 SET b=6 WHERE a=2;
XA COMMIT 'a';

With this test case, the bug is also repeatable on 5.5.
Not repeatable on 5.1.
[10 Feb 2011 13:57] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/131043

3638 Jon Olav Hauglid	2011-02-10
      Bug #59986 Assert in Diagnostics_area::set_ok_status() for XA COMMIT
      
      This assert was triggered if XA COMMIT was issued when an XA transaction
      already had encountered an error (e.g. a deadlock) which required
      the XA transaction to be rolled back.
      
      In general, the assert is triggered if a statement tries to send OK to
      the client when an error has already been reported. It was triggered
      in this case because the trans_xa_commit() function first reported an
      error, then rolled back the transaction and finally returned FALSE,
      indicating success. Since trans_xa_commit() reported success,
      mysql_execute_command() tried to report OK, triggering the assert.
      
      This patch fixes the problem by fixing trans_xa_commit() to return TRUE
      if it encounters an error that requires rollback, even if the rollback
      itself is successful.
      
      Test case added to xa.test.
[6 Apr 2011 1:45] Paul DuBois
Noted in 5.5.11, 5.6.2 changelogs.

An assertion was raised if an XA COMMIT was issued when an XA 
transaction had already encountered an error (such as a deadlock)
that required the transaction to be rolled back.

CHANGESET - http://lists.mysql.com/commits/131185

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.041 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.