Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1(EOL)
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.
Attachments
Activity
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;
|
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.