Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.14
-
Fix Version/s: 10.0.15
-
Component/s: Storage Engine - Connect
-
Labels:
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
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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?
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.