Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: N/A
-
Fix Version/s: N/A
-
Component/s: Replication
-
Labels:None
Description
The failure happens on 10.0 + patches from MDEV-7818. I couldn't reproduce it on the current main tree without the patches.
sql/rpl_parallel.cc:380: void pool_mark_busy(rpl_parallel_thread_pool*): Assertion `!pool->busy' failed. 150614 18:40:00 [ERROR] mysqld got signal 6 ;
Stack trace from 10.0 commit 36f37a4890a5407dc523fe6d1766e4dc2c57d70f + patches from MDEV-7818
#6 0x00007f518a4e7311 in *__GI___assert_fail (assertion=0xf72b51 "!pool->busy", file=<optimized out>, line=380, function=0xf740a0 "void pool_mark_busy(rpl_parallel_thread_pool*)") at assert.c:81 #7 0x00000000007f80cb in pool_mark_busy (pool=0x189d8e0) at sql/rpl_parallel.cc:380 #8 0x00000000007f8356 in rpl_pause_for_ftwrl (thd=0x7f51853eb070) at sql/rpl_parallel.cc:449 #9 0x0000000000682933 in mysql_execute_command (thd=0x7f51853eb070) at sql/sql_parse.cc:4282 #10 0x00000000009afc04 in sp_instr_stmt::exec_core (this=0x7f51820bef88, thd=0x7f51853eb070, nextp=0x7f518c614978) at sql/sp_head.cc:3204 #11 0x00000000009af355 in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f51820befc8, thd=0x7f51853eb070, nextp=0x7f518c614978, open_tables=false, instr=0x7f51820bef88) at sql/sp_head.cc:2971 #12 0x00000000009af90e in sp_instr_stmt::execute (this=0x7f51820bef88, thd=0x7f51853eb070, nextp=0x7f518c614978) at sql/sp_head.cc:3120 #13 0x00000000009ab726 in sp_head::execute (this=0x7f51820bd088, thd=0x7f51853eb070, merge_da_on_success=true) at sql/sp_head.cc:1371 #14 0x00000000009ad3d2 in sp_head::execute_procedure (this=0x7f51820bd088, thd=0x7f51853eb070, args=0x7f51853ef670) at sql/sp_head.cc:2159 #15 0x0000000000683d61 in mysql_execute_command (thd=0x7f51853eb070) at sql/sql_parse.cc:4714 #16 0x00000000006884e9 in mysql_parse (thd=0x7f51853eb070, rawbuf=0x7f5182022088 "CALL pr()", length=9, parser_state=0x7f518c615600) at sql/sql_parse.cc:6542 #17 0x000000000067ae7b in dispatch_command (command=COM_QUERY, thd=0x7f51853eb070, packet=0x7f51853f1071 "CALL pr()", packet_length=9) at sql/sql_parse.cc:1308 #18 0x000000000067a161 in do_command (thd=0x7f51853eb070) at sql/sql_parse.cc:999 #19 0x000000000079827b in do_handle_one_connection (thd_arg=0x7f51853eb070) at sql/sql_connect.cc:1375 #20 0x0000000000797fce in handle_one_connection (arg=0x7f51853eb070) at sql/sql_connect.cc:1289 #21 0x0000000000cd8337 in pfs_spawn_thread (arg=0x7f5184584af0) at storage/perfschema/pfs.cc:1860 #22 0x00007f518c2e1b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #23 0x00007f518a59795d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
Test case to reproduce (not to be included into the test suite)
--source include/have_log_bin.inc --source include/have_binlog_format_row.inc CREATE TABLE t1 (pk INT AUTO_INCREMENT PRIMARY KEY, i INT); CREATE TABLE t2 (pk INT AUTO_INCREMENT PRIMARY KEY, i INT); CREATE PROCEDURE pr() FLUSH TABLES WITH READ LOCK; --connect (con1,localhost,root,,) --let $con1 = `SELECT CONNECTION_ID()` --send CALL pr() --connect (con2,localhost,root,,) --let $con2 = `SELECT CONNECTION_ID()` --send CALL pr() --connection default --sleep 120 eval KILL $con1; eval KILL $con2; --echo # Nothing happened, finishing. DROP TABLE t1, t2; DROP PROCEDURE pr;
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
MDEV-7818 NEED REVIEW: Deadlock occurring with parallel replication and FTWRL
-
- Stalled
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Thanks for testing this, Elena.
I fixed the problem (I hope, at least the test case passes). I updated the
links to the patches in the MDEV-7818 (this is not pushed yet, still waiting
for reply to my review request).
The new list of patches for MDEV-7818, with this
MDEV-8318fixed:http://lists.askmonty.org/pipermail/commits/2015-June/008059.html
http://lists.askmonty.org/pipermail/commits/2015-June/008060.html
http://lists.askmonty.org/pipermail/commits/2015-June/008061.html