Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-8318

Assertion `!pool->busy' failed in pool_mark_busy(rpl_parallel_thread_pool*) on concurrent FTWRL

    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

              Activity

              Hide
              knielsen Kristian Nielsen added a comment -

              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-8318 fixed:

              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

              Show
              knielsen Kristian Nielsen added a comment - 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-8318 fixed: 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

                People

                • Assignee:
                  knielsen Kristian Nielsen
                  Reporter:
                  elenst Elena Stepanova
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: