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

Assertion `! is_set()' failed on FLUSH TABLES with a CONNECT table under lock

Details

    Description

      MariaDB [test]> install soname 'ha_connect';
      Query OK, 0 rows affected (0.00 sec)
       
      MariaDB [test]> create table t1 (i int) engine=Connect;
      Query OK, 0 rows affected, 2 warnings (0.20 sec)
       
      MariaDB [test]> lock table t1 write;
      Query OK, 0 rows affected (0.00 sec)
       
      MariaDB [test]> flush tables;
      ERROR 2013 (HY000): Lost connection to MySQL server during query

      sql/sql_error.cc:378: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `! is_set()' failed.
      141101  3:16:49 [ERROR] mysqld got signal 6 ;

      #6  0x00007f8134d9b6f1 in *__GI___assert_fail (assertion=0xf139a7 "! is_set()", file=<optimized out>, line=378, function=0xf147a0 "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:81
      #7  0x0000000000656cac in Diagnostics_area::set_ok_status (this=0x7f811c71c0d8, affected_rows=0, last_insert_id=0, message=0x0) at 10.0/sql/sql_error.cc:378
      #8  0x00000000006140b6 in my_ok (thd=0x7f811c717070, affected_rows=0, id=0, message=0x0) at 10.0/sql/sql_class.h:3758
      #9  0x0000000000680128 in mysql_execute_command (thd=0x7f811c717070) at 10.0/sql/sql_parse.cc:4284
      #10 0x000000000068583d in mysql_parse (thd=0x7f811c717070, rawbuf=0x7f810a822088 "flush tables", length=12, parser_state=0x7f8136d1f680) at 10.0/sql/sql_parse.cc:6406
      #11 0x0000000000678652 in dispatch_command (command=COM_QUERY, thd=0x7f811c717070, packet=0x7f811c618071 "flush tables", packet_length=12) at 10.0/sql/sql_parse.cc:1299
      #12 0x00000000006779f7 in do_command (thd=0x7f811c717070) at 10.0/sql/sql_parse.cc:996
      #13 0x0000000000794312 in do_handle_one_connection (thd_arg=0x7f811c717070) at 10.0/sql/sql_connect.cc:1379
      #14 0x0000000000794065 in handle_one_connection (arg=0x7f811c717070) at 10.0/sql/sql_connect.cc:1293
      #15 0x00007f8136954b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
      #16 0x00007f8134e4c20d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

      revision-id: svoj@mariadb.org-20141022143349-2lqyg0ao30irpmma
      date: 2014-10-22 18:33:49 +0400
      build-date: 2014-11-01 03:20:19 +0400
      revno: 4451
      branch-nick: 10.0

      Attachments

        Activity

          bertrandop Olivier Bertrand added a comment - - edited

          Once more that infamous DBUG_ASSERT stroke. Instead of displaying the error saying that FLUSH is an unsupported command for CONNECT (that it should not be) it causes the server to crash. Besides, this crash does not occur in production mode.

          Anyway it is fixed and FLUSH is now treated by CONNECT like UNLOCK. But this might still happen for other unsupported commands.

          bertrandop Olivier Bertrand added a comment - - edited Once more that infamous DBUG_ASSERT stroke. Instead of displaying the error saying that FLUSH is an unsupported command for CONNECT (that it should not be) it causes the server to crash. Besides, this crash does not occur in production mode. Anyway it is fixed and FLUSH is now treated by CONNECT like UNLOCK. But this might still happen for other unsupported commands.

          To my understanding, the assertion failure should never happen if the code handles the error properly.
          If it's not so, and there is a path in the code when the assertion fails even on something officially unsupported, could you please create a bug report about it with an example? Or maybe you already have?

          elenst Elena Stepanova added a comment - To my understanding, the assertion failure should never happen if the code handles the error properly. If it's not so, and there is a path in the code when the assertion fails even on something officially unsupported, could you please create a bug report about it with an example? Or maybe you already have?

          People

            bertrandop Olivier Bertrand
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.