[MDEV-4444] Server crashes with "safe_mutex: Trying to destroy a mutex share->mutex that was locked" on attempt to recover an archive table Created: 2013-04-26  Updated: 2013-06-14  Resolved: 2013-06-14

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.2, 5.5.30, 5.1.67, 5.2.14, 5.3.12
Fix Version/s: 10.0.4, 5.5.32, 5.1.73, 5.2.15, 5.3.13

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates

 Description   

safe_mutex: Trying to destroy a mutex share->mutex that was locked at /home/elenst/bzr/5.5/storage/archive/ha_archive.cc, line 1417 at /home/elenst/bzr/5.5/storage/archive/ha_archive.cc, line 465
130426 21:17:12 [ERROR] mysqld got signal 6 ;

#5  0x00007f6c2a52ab8b in __GI_abort () at abort.c:91
#6  0x0000000000cbe55c in safe_mutex_destroy (mp=0x7f6c14089af8, file=0xdebec0 "/home/elenst/bzr/5.5/storage/archive/ha_archive.cc", line=465) at /home/elenst/bzr/5.5/mysys/thr_mutex.c:601
#7  0x000000000096114d in inline_mysql_mutex_destroy (that=0x7f6c14089af8, src_file=0xdebec0 "/home/elenst/bzr/5.5/storage/archive/ha_archive.cc", src_line=465) at /home/elenst/bzr/5.5/include/mysql/psi/mysql_thread.h:593
#8  0x000000000096276b in ha_archive::free_share (this=0x7f6c14025938) at /home/elenst/bzr/5.5/storage/archive/ha_archive.cc:465
#9  0x0000000000962c3d in ha_archive::close (this=0x7f6c14025938) at /home/elenst/bzr/5.5/storage/archive/ha_archive.cc:640
#10 0x00000000007cc0fc in handler::ha_close (this=0x7f6c14025938) at /home/elenst/bzr/5.5/sql/handler.cc:2303
#11 0x00000000006d83d9 in closefrm (table=0x7f6c14043560, free_share=true) at /home/elenst/bzr/5.5/sql/table.cc:2705
#12 0x00000000005acae7 in intern_close_table (table=0x7f6c14043560) at /home/elenst/bzr/5.5/sql/sql_base.cc:926
#13 0x00000000005acb54 in free_cache_entry (table=0x7f6c14043560) at /home/elenst/bzr/5.5/sql/sql_base.cc:949
#14 0x00000000005ae33a in close_thread_table (thd=0x24fa500, table_ptr=0x24fa5b8) at /home/elenst/bzr/5.5/sql/sql_base.cc:1636
#15 0x00000000005ad9a6 in close_open_tables (thd=0x24fa500) at /home/elenst/bzr/5.5/sql/sql_base.cc:1371
#16 0x00000000005ae031 in close_thread_tables (thd=0x24fa500) at /home/elenst/bzr/5.5/sql/sql_base.cc:1583
#17 0x0000000000720b50 in mysql_admin_table(THD *, TABLE_LIST *, HA_CHECK_OPT *, const char *, thr_lock_type, bool, bool, uint, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *), struct {...}, int (*)(THD *, TABLE_LIST *)) (thd=0x24fa500, tables=0x7f6c14007590, check_opt=0x24fd998, operator_name=0xd4d4e5 "repair", lock_type=TL_WRITE, open_for_modify=false, repair_table_use_frm=false, extra_open_options=32, prepare_func=0x71df95 <prepare_for_repair(THD*, TABLE_LIST*, HA_CHECK_OPT*)>, operator_func=(int (handler::*)(handler * const, THD *, HA_CHECK_OPT *)) 0x7ce4b4 <handler::ha_repair(THD*, st_ha_check_opt*)>, view_operator_func=0) at /home/elenst/bzr/5.5/sql/sql_admin.cc:904
#18 0x000000000072158d in Repair_table_statement::execute (this=0x7f6c14007b60, thd=0x24fa500) at /home/elenst/bzr/5.5/sql/sql_admin.cc:1111
#19 0x0000000000615aca in mysql_execute_command (thd=0x24fa500) at /home/elenst/bzr/5.5/sql/sql_parse.cc:4475
#20 0x0000000000618cbc in mysql_parse (thd=0x24fa500, rawbuf=0x7f6c140074c8 "repair table t1", length=15, parser_state=0x7f6c1fc03500) at /home/elenst/bzr/5.5/sql/sql_parse.cc:5759
#21 0x000000000060c3bc in dispatch_command (command=COM_QUERY, thd=0x24fa500, packet=0x25eef31 "", packet_length=15) at /home/elenst/bzr/5.5/sql/sql_parse.cc:1068
#22 0x000000000060b5fd in do_command (thd=0x24fa500) at /home/elenst/bzr/5.5/sql/sql_parse.cc:794
#23 0x000000000071090d in do_handle_one_connection (thd_arg=0x24fa500) at /home/elenst/bzr/5.5/sql/sql_connect.cc:1266
#24 0x00000000007102f4 in handle_one_connection (arg=0x24fa500) at /home/elenst/bzr/5.5/sql/sql_connect.cc:1181
#25 0x000000000095d648 in pfs_spawn_thread (arg=0x25877e0) at /home/elenst/bzr/5.5/storage/perfschema/pfs.cc:1015
#26 0x00007f6c2b2f0e9a in start_thread (arg=0x7f6c1fc04700) at pthread_create.c:308
#27 0x00007f6c2a5e4cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Stack trace from:

revision-id: knielsen@knielsen-hq.org-20130422142239-e1b8ly4fsw30i2c5
revno: 3734
branch-nick: 5.5

Also reproducible on all of 5.1, 5.2, 5.3, 10.0 (on 5.1 the error and stack trace is somewhat different)

Test case:

--source include/have_archive.inc
 
--let $datadir = `SELECT @@datadir`
 
create table t1 (a int) engine=archive;
insert into t1 values (1);
--remove_file $datadir/test/t1.ARZ
--error 13,1017
select * from t1;
--error ER_CRASHED_ON_USAGE
insert into t1 values (2);
repair table t1;

For a note, MySQL also fails, but in a different fashion, with

mysqld: /home/elenst/bzr/mysql-5.6/mysys/my_seek.c:57: my_seek: Assertion `fd != -1' failed.
17:59:56 UTC - mysqld got signal 6 ;

(all of 5.1, 5.5, 5.6)



 Comments   
Comment by Elena Stepanova [ 2013-04-26 ]

Filed MySQL variation of the failure as http://bugs.mysql.com/bug.php?id=69086 (same scenario, different assertion).

Generated at Thu Feb 08 06:56:27 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.