[MDEV-12951] Server crash [mysqld got exception 0xc0000005] Created: 2017-05-30  Updated: 2018-03-22  Resolved: 2017-09-26

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Federated
Affects Version/s: 10.2.6, 10.2.8
Fix Version/s: 10.2.9

Type: Bug Priority: Major
Reporter: Estrategy | Support Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: innodb
Environment:

Windows 10 pro, Windows Server 2012R2

Issue Links:
Relates
relates to MDEV-12725 select on federated table crashes server Closed
relates to MDEV-13163 10.1.24-MariaDB crash report Closed
relates to MDEV-14272 Mariadb crashes with signal 11 when u... Closed
relates to MDEV-14414 mysqld got signal 11 Closed
relates to MDEV-15617 [ERROR] mysqld got signal 11 ; Closed

 Description   

Server will crash after some time, after updating from 10.1.17. I think the same error is also been throwed on 10.1.23. I did a mysql_upgrade after replacing the binary files.
Probably this query is executed on a federated table.

[Note] C:\Program Files\MariaDB\bin\mysqld: ready for connections.
 
Version: '10.2.6-MariaDB'  socket: ''  port: 3306  mariadb.org binary distribution
 
170530 13:08:32 [ERROR] mysqld got exception 0xc0000005 ;
 
This could be because you hit a bug. It is also possible that this binary
 
or one of the libraries it was linked against is corrupt, improperly built,
 
or misconfigured. This error can also be caused by malfunctioning hardware.
 
 
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
 
 
We will try our best to scrape up some info that will hopefully help
 
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.
 
 
 
Server version: 10.2.6-MariaDB
 
key_buffer_size=402653184
 
read_buffer_size=2097152
 
max_used_connections=11
 
max_threads=65537
 
thread_count=9
 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 400090 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x2c57c7de8c8
 
Attempting backtrace. You can use the following information to find out
 
where mysqld died. If you see no messages after this, something went
 
terribly wrong...
 
mysqld.exe!Query_cache_block::headers_len()[sql_cache.cc:843]
 
mysqld.exe!Query_cache_block::data()[sql_cache.cc:850]
 
mysqld.exe!Query_cache::insert()[sql_cache.cc:1096]
 
mysqld.exe!query_cache_insert()[sql_cache.cc:1059]
 
mysqld.exe!net_real_write()[net_serv.cc:622]
 
mysqld.exe!net_flush()[net_serv.cc:378]
 
mysqld.exe!net_write_command()[net_serv.cc:514]
 
mysqld.exe!cli_advanced_command()[client.c:708]
 
mysqld.exe!mysql_send_query()[client.c:4061]
 
mysqld.exe!mysql_real_query()[client.c:4071]
 
ha_federated.dll!ha_federated::real_query()[ha_federated.cc:3209]
 
ha_federated.dll!ha_federated::info()[ha_federated.cc:2833]
 
mysqld.exe!TABLE_LIST::fetch_number_of_rows()[table.cc:7920]
 
mysqld.exe!make_join_statistics()[sql_select.cc:3802]
 
mysqld.exe!JOIN::optimize_inner()[sql_select.cc:1508]
 
mysqld.exe!JOIN::optimize()[sql_select.cc:1085]
 
mysqld.exe!mysql_select()[sql_select.cc:3652]
 
mysqld.exe!handle_select()[sql_select.cc:361]
 
mysqld.exe!execute_sqlcom_select()[sql_parse.cc:6431]
 
mysqld.exe!mysql_execute_command()[sql_parse.cc:3448]
 
mysqld.exe!sp_instr_stmt::exec_core()[sp_head.cc:3236]
 
mysqld.exe!sp_lex_keeper::reset_lex_and_exec_core()[sp_head.cc:2997]
 
mysqld.exe!sp_instr_stmt::execute()[sp_head.cc:3150]
 
mysqld.exe!sp_head::execute()[sp_head.cc:1323]
 
mysqld.exe!sp_head::execute_procedure()[sp_head.cc:2112]
 
mysqld.exe!do_execute_sp()[sql_parse.cc:2883]
 
mysqld.exe!mysql_execute_command()[sql_parse.cc:5787]
 
mysqld.exe!mysql_parse()[sql_parse.cc:7879]
 
mysqld.exe!dispatch_command()[sql_parse.cc:1814]
 
mysqld.exe!do_command()[sql_parse.cc:1361]
 
mysqld.exe!threadpool_process_request()[threadpool_common.cc:346]
 
mysqld.exe!tp_callback()[threadpool_common.cc:192]
 
ntdll.dll!TpReleaseWork()
 
ntdll.dll!TpReleaseWork()
 
KERNEL32.DLL!BaseThreadInitThunk()
 
ntdll.dll!RtlUserThreadStart()
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x2c57d791a20): SELECT
 
 
 
		s.`id`,
 
 
 
		s.`active`,
 
 
 
		CAST(AES_DECRYPT(s.`name`,  NAME_CONST('i_name_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `name`,
 
 
 
		CAST(AES_DECRYPT(s.`visitaddress`,  NAME_CONST('i_visitaddress_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `visitaddress`,
 
 
 
		CAST(AES_DECRYPT(s.`visitzipcode`,  NAME_CONST('i_visitzipcode_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `visitzipcode`,
 
 
 
		CAST(AES_DECRYPT(s.`visitcity`,  NAME_CONST('i_visitcity_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `visitcity`,
 
 
 
		CAST(AES_DECRYPT(s.`visitcountry`,  NAME_CONST('i_visitcountry_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `visitcountry`,
 
 
 
		CAST(AES_DECRYPT(s.`invoicename`,  NAME_CONST('i_invoicename_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `invoicename`,
 
 
 
		CAST(AES_DECRYPT(s.`invoiceaddress`,  NAME_CONST('i_invoiceaddress_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `invoiceaddress`,
 
 
 
		CAST(AES_DECRYPT(s.`invoicezipcode`,  NAME_CONST('i_invoicezipcode_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `invoicezipcode`,
 
 
 
		CAST(AES_DECRYPT(s.`invoicecity`,  NAME_CONST('i_invoicecity_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `invoicecity`,
 
 
 
		CAST(AES_DECRYPT(s.`invoicecountry`,  NAME_CONST('i_invoicecountry_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `invoicecountry`,
 
 
 
		CAST(AES_DECRYPT(s.`invoiceemail`,  NAME_CONST('i_invoiceemail_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `invoiceemail`,
 
 
 
		CAST(AES_DECRYPT(s.`phone`,  NAME_CONST('i_phone_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `phone`,
 
 
 
		CAST(AES_DECRYPT(s.`email`,  NAME_CONST('i_email_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `email`,
 
 
 
		s.`reference`,
 
 
 
		CAST(AES_DECRYPT(s.`brincode`,  NAME_CONST('i_brincode_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `brincode`,
 
 
 
		s.`dependancecode`,
 
 
 
		CAST(AES_DECRYPT(s.`lrk`,  NAME_CONST('i_lrk_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `lrk`,
 
 
 
		CAST(AES_DECRYPT(s.`contactperson`,  NAME_CONST('i_contactperson_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `contactperson`,
 
 
 
		s.`isdemo`,
 
 
 
		CAST(AES_DECRYPT(s.`management`,  NAME_CONST('i_management_key',_utf8'EncryptKey' COLLATE 'utf8_general_ci')) AS CHAR CHARACTER SET utf8) AS `management`,
 
 
 
		s.`createdby`,
 
 
 
		s.`dtcreated`,
 
 
 
		s.`lastupdatedby`,
 
 
 
		s.`dtlastupdated`
 
 
 
	FROM `school` s
 
 
 
	WHERE s.id =  NAME_CONST('i_id',1)
 
Connection ID (thread ID): 71
 
Status: NOT_KILLED
 
 
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on



 Comments   
Comment by Elena Stepanova [ 2017-06-02 ]

Could you please paste the output of 

SHOW CREATE TABLE school;
 
SHOW INDEX IN school;

and the same queries for the underlying table if it's federated.

Please also attach your ini file(s).

Comment by Estrategy | Support [ 2017-06-06 ] 

CREATE TABLE `school` (
 
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
 
  `active` bit(1) NOT NULL DEFAULT b'1',
 
  `name` varbinary(112) NOT NULL,
 
  `visitaddress` varbinary(112) DEFAULT NULL COMMENT '@@VisitAddress@@',
 
  `visitzipcode` varbinary(16) DEFAULT NULL COMMENT '@@VisitZipCode@@',
 
  `visitcity` varbinary(112) DEFAULT NULL COMMENT '@@VisitCity@@',
 
  `visitcountry` varbinary(112) DEFAULT NULL COMMENT '@@VisitCountry@@',
 
  `invoicename` varbinary(112) DEFAULT NULL COMMENT '@@InvoiceName@@',
 
  `invoiceaddress` varbinary(112) DEFAULT NULL COMMENT '@@InvoiceAddress@@',
 
  `invoicezipcode` varbinary(16) DEFAULT NULL COMMENT '@@InvoiceZipCode@@',
 
  `invoicecity` varbinary(112) DEFAULT NULL COMMENT '@@InvoiceCity@@',
 
  `invoicecountry` varbinary(112) DEFAULT NULL COMMENT '@@InvoiceCountry@@',
 
  `invoiceemail` varbinary(112) DEFAULT NULL COMMENT '@@InvoiceEmail@@',
 
  `phone` varbinary(48) DEFAULT NULL,
 
  `email` varbinary(112) DEFAULT NULL,
 
  `reference` varchar(36) DEFAULT NULL,
 
  `brincode` varbinary(16) DEFAULT NULL COMMENT '@@BrinCode@@',
 
  `dependancecode` varchar(5) DEFAULT NULL COMMENT '@@DependanceCode@@',
 
  `lrk` varbinary(16) DEFAULT NULL COMMENT '@@LRK@@',
 
  `contactperson` varbinary(256) DEFAULT NULL COMMENT '@@ContactPerson@@',
 
  `isdemo` bit(1) NOT NULL DEFAULT b'0' COMMENT '@@IsDemo@@',
 
  `management` varbinary(112) DEFAULT '!�^��l����c�',
 
  `createdby` int(10) NOT NULL COMMENT '@@CreatedBy@@',
 
  `dtcreated` datetime NOT NULL COMMENT '@@DateTimeCreated@@',
 
  `lastupdatedby` int(10) NOT NULL COMMENT '@@LastUpdatedBy@@',
 
  `dtlastupdated` datetime NOT NULL COMMENT '@@DateTimeLastUpdated@@',
 
  PRIMARY KEY (`id`),
 
  UNIQUE KEY `uidx_school_reference` (`reference`)
 
) ENGINE=InnoDB AUTO_INCREMENT=6850 DEFAULT CHARSET=utf8


Table VARCHAR(64), Non_unique BIGINT(1), Key_name VARCHAR(64), Seq_in_index BIGINT(2), Column_name VARCHAR(64), Collation VARCHAR(1), Cardinality BIGINT(21), Sub_part BIGINT(3), Packed VARCHAR(10), Null VARCHAR(3), Index_type VARCHAR(16), Comment VARCHAR(16), Index_comment VARCHAR(1024)
 
school	0	PRIMARY	1	id	A	4719	(null)	(null)		BTREE		
school	0	uidx_school_reference	1	reference	A	4719	(null)	(null)	YES	BTREE

Federated:

CREATE TABLE `school` (
 
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
 
  `active` bit(1) NOT NULL DEFAULT b'1',
 
  `name` varbinary(112) NOT NULL,
 
  `visitaddress` varbinary(112) DEFAULT NULL COMMENT '@@VisitAddress@@',
 
  `visitzipcode` varbinary(16) DEFAULT NULL COMMENT '@@VisitZipCode@@',
 
  `visitcity` varbinary(112) DEFAULT NULL COMMENT '@@VisitCity@@',
 
  `visitcountry` varbinary(112) DEFAULT NULL COMMENT '@@VisitCountry@@',
 
  `invoicename` varbinary(112) DEFAULT NULL COMMENT '@@InvoiceName@@',
 
  `invoiceaddress` varbinary(112) DEFAULT NULL COMMENT '@@InvoiceAddress@@',
 
  `invoicezipcode` varbinary(16) DEFAULT NULL COMMENT '@@InvoiceZipCode@@',
 
  `invoicecity` varbinary(112) DEFAULT NULL COMMENT '@@InvoiceCity@@',
 
  `invoicecountry` varbinary(112) DEFAULT NULL COMMENT '@@InvoiceCountry@@',
 
  `invoiceemail` varbinary(112) DEFAULT NULL COMMENT '@@InvoiceEmail@@',
 
  `phone` varbinary(48) DEFAULT NULL,
 
  `email` varbinary(112) DEFAULT NULL,
 
  `reference` varchar(36) DEFAULT NULL,
 
  `brincode` varbinary(16) DEFAULT NULL COMMENT '@@BrinCode@@',
 
  `dependancecode` varchar(5) DEFAULT NULL COMMENT '@@DependanceCode@@',
 
  `lrk` varbinary(16) DEFAULT NULL COMMENT '@@LRK@@',
 
  `contactperson` varbinary(256) DEFAULT NULL COMMENT '@@ContactPerson@@',
 
  `isdemo` bit(1) NOT NULL DEFAULT b'0' COMMENT '@@IsDemo@@',
 
  `management` varbinary(112) DEFAULT '!�^��l����c�',
 
  `createdby` int(10) NOT NULL COMMENT '@@CreatedBy@@',
 
  `dtcreated` datetime NOT NULL COMMENT '@@DateTimeCreated@@',
 
  `lastupdatedby` int(10) NOT NULL COMMENT '@@LastUpdatedBy@@',
 
  `dtlastupdated` datetime NOT NULL COMMENT '@@DateTimeLastUpdated@@',
 
  PRIMARY KEY (`id`),
 
  UNIQUE KEY `uidx_school_reference` (`reference`)
 
) ENGINE=FEDERATED DEFAULT CHARSET=utf8 CONNECTION='licenceadministration/school'


Table VARCHAR(64), Non_unique BIGINT(1), Key_name VARCHAR(64), Seq_in_index BIGINT(2), Column_name VARCHAR(64), Collation VARCHAR(1), Cardinality BIGINT(21), Sub_part BIGINT(3), Packed VARCHAR(10), Null VARCHAR(3), Index_type VARCHAR(16), Comment VARCHAR(16), Index_comment VARCHAR(1024)
 
school	0	PRIMARY	1	id	(null)	(null)	(null)	(null)		REMOTE		
school	0	uidx_school_reference	1	reference	(null)	(null)	(null)	(null)	YES	REMOTE		


[client]
 
character_set_client=latin1
 
 
 
[mysql]
 
default-character-set=latin1
 
no-auto-rehash
 
 
 
[mysqld]
 
character-set-server=utf8
 
port		= 3306
 
skip-external-locking
 
key_buffer_size = 16K
 
max_allowed_packet = 32M
 
table_open_cache = 4
 
sort_buffer_size = 64K
 
read_buffer_size = 256K
 
read_rnd_buffer_size = 256K
 
net_buffer_length = 2K
 
thread_stack = 240K
 
 
 
event-scheduler = ON
 
federated
 
 
 
basedir="C:\\Program Files\\MariaDB"
 
datadir="D:\\ProgramData\\MariaDB\\3306\\data\\"
 
general_log_file="D:\\ProgramData\\MariaDB\\3306\\log\\3306.log"
 
log-error="D:\\ProgramData\\MariaDB\\3306\\log\\3306.err"
 
 
 
innodb_data_file_path = ibdata1:10M:autoextend
 
innodb_buffer_pool_size = 16M
 
innodb_log_file_size = 256M
 
innodb_log_buffer_size = 8M
 
innodb_flush_log_at_trx_commit = 1
 
innodb_lock_wait_timeout = 50
 
 
 
innodb_print_all_deadlocks=ON
 
query_cache_type=1
 
 
 
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
 
 
 
 
 
feedback=OFF
 
 
 
[mysqldump]
 
quick
 
max_allowed_packet = 64M
 
 
 
 
 
[myisamchk]
 
key_buffer_size = 8M
 
sort_buffer_size = 8M
 
 
 
[mysqlhotcopy]
 
interactive-timeout

It seems to crash on different queries, not always instantly. like the one in the first post

Comment by Elena Stepanova [ 2017-06-25 ]

Thank you. Given the stack trace and the timing (versions), it appears to be the same problem as MDEV-12725. You can track further progress there.

Comment by Estrategy | Support [ 2017-08-23 ]

Problem still exists within v10.2.8. Please reinvestigate.

Comment by Elena Stepanova [ 2017-08-23 ]

EstrategySupport,

The query in question is executed from inside a stored routine. Could you please provide its definition?
If you don't want to make it public, you can upload it to ftp.askmonty.org/private.

Comment by Elena Stepanova [ 2017-08-23 ]

Thanks. It looks like there is nothing special about the procedure.

Whether with the given structures or with primitive ones, I still can only get a somewhat similar crash or valgrind error on server shutdown, but not on an actual query. The test case is pretty much the same as in MDEV-12725, with one additional SELECT; only in MDEV-12725 the reporter and we used FederatedX, which seems to be fixed now (for this test case, anyway), and here we use Federated, which still crashes.

--source include/have_innodb.inc
 
 
 
INSTALL SONAME 'ha_federated';
 
 
 
SET GLOBAL query_cache_size= 16*1024*1024;
 
SET GLOBAL query_cache_type= 1;
 
 
CREATE TABLE t1 (i INT) ENGINE=InnoDB;
 
eval
 
CREATE TABLE t2 (i INT) ENGINE=FEDERATED 
  CONNECTION="mysql://root@localhost:$MASTER_MYPORT/test/t1";
 
 
 
SELECT * FROM t2;

10.2 valgrind build 59caf2c3c1fe

 
==21569== Invalid read of size 8
 
==21569==    at 0x658DEC: Query_cache::insert(THD*, Query_cache_tls*, char const*, unsigned long, unsigned int) (sql_cache.cc:1074)
 
==21569==    by 0x658D95: query_cache_insert(void*, char const*, unsigned long, unsigned int) (sql_cache.cc:1058)
 
==21569==    by 0x5E3095: net_real_write (net_serv.cc:619)
 
==21569==    by 0x5E2983: net_flush (net_serv.cc:376)
 
==21569==    by 0x5E2DBD: net_write_command (net_serv.cc:514)
 
==21569==    by 0x8F15D1: cli_advanced_command (client.c:708)
 
==21569==    by 0x8F892F: mysql_close_slow_part (client.c:3950)
 
==21569==    by 0x8F89AC: mysql_close (client.c:3962)
 
==21569==    by 0x1D4B051E: ha_federated::close() (ha_federated.cc:1691)
 
==21569==    by 0x936C26: handler::ha_close() (handler.cc:2534)
 
==21569==    by 0x7BB219: closefrm(TABLE*) (table.cc:3412)
 
==21569==    by 0x8A91F3: intern_close_table(TABLE*) (table_cache.cc:222)
 
==21569==    by 0x8A95FA: tc_purge(bool) (table_cache.cc:335)
 
==21569==    by 0x63FC81: close_cached_tables(THD*, TABLE_LIST*, bool, unsigned long) (sql_base.cc:374)
 
==21569==    by 0x8AA634: tdc_start_shutdown() (table_cache.cc:645)
 
==21569==    by 0x5D20A7: clean_up(bool) (mysqld.cc:2212)

10.2 debug build 86fc5ece26f0

 
#3  <signal handler called>
 
#4  0x0000563c6a9b8b49 in QUERY_PROFILE::new_status (this=0x8f8f8f8f8f8f8f8f, status_arg=0x563c6b2bb6b2 "Waiting for query cache lock", function_arg=0x563c6b2d137b <Query_cache::try_lock(THD*, Query_cache::Cache_try_lock_mode)::__FUNCTION__> "try_lock", file_arg=0x563c6b2ceb70 "/data/src/10.2/sql/sql_cache.cc", line_arg=604) at /data/src/10.2/sql/sql_profile.cc:312
 
#5  0x0000563c6a79f114 in PROFILING::status_change (this=0x7fe3a80040a0, status_arg=0x563c6b2bb6b2 "Waiting for query cache lock", function_arg=0x563c6b2d137b <Query_cache::try_lock(THD*, Query_cache::Cache_try_lock_mode)::__FUNCTION__> "try_lock", file_arg=0x563c6b2ceb70 "/data/src/10.2/sql/sql_cache.cc", line_arg=604) at /data/src/10.2/sql/sql_profile.h:312
 
#6  0x0000563c6a79f6ef in THD::enter_stage (this=0x7fe3a8000b00, stage=0x563c6bbb4e10 <stage_waiting_for_query_cache_lock>, calling_func=0x563c6b2d137b <Query_cache::try_lock(THD*, Query_cache::Cache_try_lock_mode)::__FUNCTION__> "try_lock", calling_file=0x563c6b2ceb70 "/data/src/10.2/sql/sql_cache.cc", calling_line=604) at /data/src/10.2/sql/sql_class.h:2182
 
#7  0x0000563c6a823a46 in set_thd_stage_info (thd_arg=0x7fe3a8000b00, new_stage=0x563c6bbb4e10 <stage_waiting_for_query_cache_lock>, old_stage=0x7fe4090056b8, calling_func=0x563c6b2d137b <Query_cache::try_lock(THD*, Query_cache::Cache_try_lock_mode)::__FUNCTION__> "try_lock", calling_file=0x563c6b2ceb70 "/data/src/10.2/sql/sql_cache.cc", calling_line=604) at /data/src/10.2/sql/sql_class.cc:389
 
#8  0x0000563c6a821fea in Query_cache_wait_state::Query_cache_wait_state (this=0x7fe4090056b0, thd=0x7fe3a8000b00, func=0x563c6b2d137b <Query_cache::try_lock(THD*, Query_cache::Cache_try_lock_mode)::__FUNCTION__> "try_lock", file=0x563c6b2ceb70 "/data/src/10.2/sql/sql_cache.cc", line=604) at /data/src/10.2/sql/sql_cache.cc:433
 
#9  0x0000563c6a813de6 in Query_cache::try_lock (this=0x563c6bdb6d40 <query_cache>, thd=0x7fe3a8000b00, mode=Query_cache::WAIT) at /data/src/10.2/sql/sql_cache.cc:604
 
#10 0x0000563c6a814f78 in Query_cache::insert (this=0x563c6bdb6d40 <query_cache>, thd=0x7fe3a8000b00, query_cache_tls=0x7fe3a8000dc0, packet=0x7fe3a803c870 "\001", length=5, pkt_nr=1) at /data/src/10.2/sql/sql_cache.cc:1083
 
#11 0x0000563c6a814ea8 in query_cache_insert (thd_arg=0x7fe3a8000b00, packet=0x7fe3a803c870 "\001", length=5, pkt_nr=1) at /data/src/10.2/sql/sql_cache.cc:1058
 
#12 0x0000563c6a7a0e24 in net_real_write (net=0x7fe3a8132a40, packet=0x7fe3a803c870 "\001", len=5) at /data/src/10.2/sql/net_serv.cc:619
 
#13 0x0000563c6a7a0712 in net_flush (net=0x7fe3a8132a40) at /data/src/10.2/sql/net_serv.cc:376
 
#14 0x0000563c6a7a0b4c in net_write_command (net=0x7fe3a8132a40, command=1 '\001', header=0x0, head_len=0, packet=0x0, len=0) at /data/src/10.2/sql/net_serv.cc:514
 
#15 0x0000563c6aaa0262 in cli_advanced_command (mysql=0x7fe3a8132a40, command=COM_QUIT, header=0x0, header_length=0, arg=0x0, arg_length=0, skip_check=1 '\001', stmt=0x0) at /data/src/10.2/sql-common/client.c:708
 
#16 0x0000563c6aaa7605 in mysql_close_slow_part (mysql=0x7fe3a8132a40) at /data/src/10.2/sql-common/client.c:3950
 
#17 0x0000563c6aaa7682 in mysql_close (mysql=0x7fe3a8132a40) at /data/src/10.2/sql-common/client.c:3962
 
#18 0x00007fe4001e02ff in ha_federated::close (this=0x7fe3a8149048) at /data/src/10.2/storage/federated/ha_federated.cc:1691
 
#19 0x0000563c6aae4513 in handler::ha_close (this=0x7fe3a8149048) at /data/src/10.2/sql/handler.cc:2534
 
#20 0x0000563c6a972c84 in closefrm (table=0x7fe3a8148440) at /data/src/10.2/sql/table.cc:3412
 
#21 0x0000563c6aa589de in intern_close_table (table=0x7fe3a8148440) at /data/src/10.2/sql/table_cache.cc:222
 
#22 0x0000563c6aa58de5 in tc_purge (mark_flushed=true) at /data/src/10.2/sql/table_cache.cc:335
 
#23 0x0000563c6a7fc05c in close_cached_tables (thd=0x0, tables=0x0, wait_for_refresh=false, timeout=31536000) at /data/src/10.2/sql/sql_base.cc:374
 
#24 0x0000563c6aa59e1f in tdc_start_shutdown () at /data/src/10.2/sql/table_cache.cc:645
 
#25 0x0000563c6a79009d in clean_up (print_message=true) at /data/src/10.2/sql/mysqld.cc:2212
 
#26 0x0000563c6a78fbe0 in unireg_end () at /data/src/10.2/sql/mysqld.cc:2088
 
#27 0x0000563c6a78fadd in kill_server (sig_ptr=0x0) at /data/src/10.2/sql/mysqld.cc:2015
 
#28 0x0000563c6a78fb1f in kill_server_thread (arg=0x7fe408189e00) at /data/src/10.2/sql/mysqld.cc:2038
 
#29 0x0000563c6add38e0 in pfs_spawn_thread (arg=0x7fe3b00013f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
 
#30 0x00007fe40efbd494 in start_thread (arg=0x7fe409006700) at pthread_create.c:333
 
#31 0x00007fe40d13593f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Comment by Sergei Golubchik [ 2017-09-26 ]

Fixed in 10.2.9

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