[MDEV-5918] Assertion `m_lock_type == 2' fails on dropping a locked CONNECT table Created: 2014-03-21  Updated: 2014-03-21  Resolved: 2014-03-21

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.9
Fix Version/s: 10.0.10

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Olivier Bertrand
Resolution: Fixed Votes: 0
Labels: connect-engine


 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



 Comments   
Comment by Olivier Bertrand [ 2014-03-21 ]

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.

Generated at Thu Feb 08 07:08:01 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.