[MDEV-8725] Assertion `!(thd->rgi_slave && thd-> rgi_slave->did_mark_start_commit)' failed in ha_rollback_trans Created: 2015-09-02  Updated: 2015-09-02  Resolved: 2015-09-02

Status: Closed
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 10.1
Fix Version/s: 10.0.22, 10.1.7

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Kristian Nielsen
Resolution: Fixed Votes: 0
Labels: parallelslave

Attachments: File binlog.tar.gz    

 Description   

Note: it's possible that 10.0 is also affected, I am currently running tests on 10.1, so it comes from there.

Stack trace from 10.1 8ea9b8c0b168b3e5aad08886477d8726531abcd5

10.1/sql/handler.cc:1632: int ha_rollback_trans(THD*, bool): Assertion `!(thd->rgi_slave && thd->
rgi_slave->did_mark_start_commit)' failed.
150902  1:23:09 [ERROR] mysqld got signal 6 ;
 
#6  0x00007fbe521a7311 in *__GI___assert_fail (assertion=0x7fbe55528fc0 "!(thd->rgi_slave && thd->rgi_slave->did_mark_start_commit)", file=<optimized out>, line=1632, function=0x7fbe5552c2e0 "int ha_rollback_trans(THD*, bool)") at assert.c:81
#7  0x00007fbe54d1aa7a in ha_rollback_trans (thd=0x7fbe26c2e070, all=true) at 10.1/sql/handler.cc:1632
#8  0x00007fbe54c26884 in trans_rollback (thd=0x7fbe26c2e070) at 10.1/sql/transaction.cc:343
#9  0x00007fbe54ae9fde in mysql_execute_command (thd=0x7fbe26c2e070) at 10.1/sql/sql_parse.cc:4962
#10 0x00007fbe54af05ef in mysql_parse (thd=0x7fbe26c2e070, rawbuf=0x7fbe260c8179 "ROLLBACK", length=8, parser_state=0x7fbe520e8a50) at 10.1/sql/sql_parse.cc:7208
#11 0x00007fbe54e0f8a5 in Query_log_event::do_apply_event (this=0x7fbe26088630, rgi=0x7fbe260af800, query_arg=0x7fbe260c8179 "ROLLBACK", q_len_arg=8) at 10.1/sql/log_event.cc:4290
#12 0x00007fbe54e0ea63 in Query_log_event::do_apply_event (this=0x7fbe26088630, rgi=0x7fbe260af800) at 10.1/sql/log_event.cc:4012
#13 0x00007fbe54a4e219 in Log_event::apply_event (this=0x7fbe26088630, rgi=0x7fbe260af800) at 10.1/sql/log_event.h:1347
#14 0x00007fbe54a43c1b in apply_event_and_update_pos (ev=0x7fbe26088630, thd=0x7fbe26c2e070, rgi=0x7fbe260af800, rpt=0x7fbe508d99c0) at 10.1/sql/slave.cc:3375
#15 0x00007fbe54c7ebf0 in rpt_handle_event (qev=0x7fbe260fa570, rpt=0x7fbe508d99c0) at 10.1/sql/rpl_parallel.cc:49
#16 0x00007fbe54c80f60 in handle_rpl_parallel_thread (arg=0x7fbe508d99c0) at 10.1/sql/rpl_parallel.cc:974
#17 0x00007fbe541c2b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#18 0x00007fbe5225795d 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 (0x7fbe260c8179): ROLLBACK
Connection ID (thread ID): 11
Status: NOT_KILLED

To reproduce, start master with the attached binary log (default options will do), start slave with slave_parallel_threads=8, set up replication, wait.



 Comments   
Comment by Kristian Nielsen [ 2015-09-02 ]

The assertion happens because the binlog contains a ROLLBACK query event.

Elena, do you know how one might inject such ROLLBACK event into the binlog (for a test case)? Maybe you can see it in the general log? Or basically any way to put a ROLLBACK event into the binlog should trigger this assertion.

Comment by Kristian Nielsen [ 2015-09-02 ]

Hm, this seems to work:

create table t1 (a int primary key, b int) engine=innodb;
create table t2 (a int primary key, b int) engine=myisam;
begin;
insert into t1 values (5,0);
insert into t2 values (1,1);
insert into t1 values (6,0);
rollback;

Comment by Kristian Nielsen [ 2015-09-02 ]

http://lists.askmonty.org/pipermail/commits/2015-September/008297.html

Generated at Thu Feb 08 07:29:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.