Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.9
-
Fix Version/s: 10.0.10
-
Component/s: None
-
Labels:
Description
CREATE TABLE t1 (i INT) ENGINE=CONNECT TABLE_TYPE=DOS FILE_NAME='t1.dos'; LOCK TABLE t1 WRITE; DROP TABLE t1;
10.0/sql/handler.cc:2492: int handler::ha_close(): Assertion `m_lock_type == 2' failed. 140321 2:28:55 [ERROR] mysqld got signal 6 ;
#6 0x00007fa644b07621 in *__GI___assert_fail (assertion=0xfdc97e "m_lock_type == 2", file=<optimized out>, line=2492, function=0xfe0050 "int handler::ha_close()") at assert.c:81 #7 0x00000000008611f6 in handler::ha_close (this=0x7fa6184cea88) at 10.0/sql/handler.cc:2492 #8 0x000000000074d381 in closefrm (table=0x7fa6184dec70, free_share=true) at 10.0/sql/table.cc:2941 #9 0x000000000060f7a4 in intern_close_table (table=0x7fa6184dec70) at 10.0/sql/sql_base.cc:342 #10 0x00000000007ed858 in tc_release_table (table=0x7fa6184dec70) at 10.0/sql/table_cache.cc:409 #11 0x0000000000610d66 in close_thread_table (thd=0x7fa626bc8070, table_ptr=0x7fa626bc8130) at 10.0/sql/sql_base.cc:1054 #12 0x0000000000610770 in close_all_tables_for_name (thd=0x7fa626bc8070, share=0x7fa6184bd688, extra=HA_EXTRA_NOT_USED, skip_table=0x0) at 10.0/sql/sql_base.cc:846 #13 0x0000000000718407 in mysql_rm_table_no_locks (thd=0x7fa626bc8070, tables=0x7fa618413150, if_exists=false, drop_temporary=false, drop_view=false, dont_log_query=false, dont_free_locks=false) at 10.0/sql/sql_table.cc:2478 #14 0x0000000000717866 in mysql_rm_table (thd=0x7fa626bc8070, tables=0x7fa618413150, if_exists=0 '\000', drop_temporary=0 '\000') at 10.0/sql/sql_table.cc:2106 #15 0x000000000067606c in mysql_execute_command (thd=0x7fa626bc8070) at 10.0/sql/sql_parse.cc:3701 #16 0x000000000067d66b in mysql_parse (thd=0x7fa626bc8070, rawbuf=0x7fa618413088 "DROP TABLE t1", length=13, parser_state=0x7fa6469cd610) at 10.0/sql/sql_parse.cc:6447 #17 0x0000000000670438 in dispatch_command (command=COM_QUERY, thd=0x7fa626bc8070, packet=0x7fa626e9b071 "DROP TABLE t1", packet_length=13) at 10.0/sql/sql_parse.cc:1308 #18 0x000000000066f7da in do_command (thd=0x7fa626bc8070) at 10.0/sql/sql_parse.cc:1005 #19 0x0000000000789e72 in do_handle_one_connection (thd_arg=0x7fa626bc8070) at 10.0/sql/sql_connect.cc:1379 #20 0x0000000000789bc5 in handle_one_connection (arg=0x7fa626bc8070) at 10.0/sql/sql_connect.cc:1293 #21 0x0000000000a2f174 in pfs_spawn_thread (arg=0x7fa626bf13f0) at 10.0/storage/perfschema/pfs.cc:1853 #22 0x00007fa6466abb50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #23 0x00007fa644bb6a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
revision-id: svoj@mariadb.org-20140320071113-ql1nx7dc9h22odx3 date: 2014-03-20 11:11:13 +0400 build-date: 2014-03-21 02:40:25 +0400 revno: 4071 branch-nick: 10.0
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
This was fixed by not returning an error code from external_lock (this command was not expected in that context)
However, this is just hiding another bug not related to CONNECT. When external_lock is called, the lock type is F_UNLCK indeed but later, when an error code is returned, a MariaDB DBUG_ASSERT test the lock type which, I don't know where, has been changed to F_RDLCK and then a signal is raised causing the server to crash. We have already discuss that matter with Sergei and I was expecting this was fix.