InnoDB: Assertion failure in thread 47550051727680 in file lock0lock.cc line 5579

Bug #1318866 reported by cooper
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC
Status tracked in 5.6
5.5
New
Undecided
Unassigned
5.6
Fix Released
Undecided
Unassigned

Bug Description

Server version: 5.6.15-rel63.0-log 5.6.15-, Percona XtraDB Cluster - binary (GPL), Release: 25.5, Revision 769 wsrep_25.5.r4061, wsrep_25.5.r40

download: Percona-XtraDB-Cluster-5.6.15-25.5.769.Linux.x86_64.tar.gz

=====error.log=====
2014-05-05 16:04:53 17177 [Note] Shutting down plugin 'XTRADB_READ_VIEW'
2014-05-05 16:04:53 17177 [Note] Shutting down plugin 'InnoDB'
2014-05-05 16:04:53 17177 [Note] InnoDB: FTS optimize thread exiting.
2014-05-05 16:04:53 17177 [Note] InnoDB: Starting shutdown...
2014-05-05 16:04:53 2b3f1bf13940 InnoDB: Assertion failure in thread 47550051727680 in file lock0lock.cc line 5579
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
08:04:53 UTC - mysqld got signal 6 ;
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.
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.
Please help us make Percona XtraDB Cluster better by reporting any
bugs at https://bugs.launchpad.net/percona-xtradb-cluster

key_buffer_size=16777216
read_buffer_size=4194304
max_used_connections=18
max_threads=1026
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 8436742 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
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...
stack_bottom = 0 thread_stack 0x40000
/home/abc/apps/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x8fef15]
/home/abc/apps/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x67cc44]
/lib64/libpthread.so.0[0x3551a0eca0]
/lib64/libc.so.6(gsignal+0x35)[0x3550e302c5]
/lib64/libc.so.6(abort+0x110)[0x3550e31d70]
/home/abc/apps/mysql/bin/mysqld[0x948018]
/home/abc/apps/mysql/bin/mysqld[0x9d7edc]
/home/abc/apps/mysql/bin/mysqld[0x9d8d62]
/lib64/libpthread.so.0[0x3551a0683d]
/lib64/libc.so.6(clone+0x6d)[0x3550ed503d]
You may download the Percona XtraDB Cluster operations manual by visiting
http://www.percona.com/software/percona-xtradb-cluster/. You may find information
in the manual which will help you identify the cause of the crash.

========================
# my.cnf
[client]
socket = /data/abc/tmp/mysql.sock
port = 3316
default-character-set = utf8

[mysqld]

# [ 基本配置 ]
server-id = 1397720344

basedir = /home/abc/apps/mysql/
datadir = /data/abc/data
user = abc
port = 3316
socket = /data/abc/tmp/mysql.sock
pid-file = /data/abc/tmp/mysql.pid

wait_timeout = 7200
net_retry_count = 100000000

thread_concurrency = 8
thread_stack = 256K

max_connections = 1024
max_connect_errors = 1024
open_files_limit = 4096
back_log = 1024

max_allowed_packet = 96M

auto_increment_increment = 1
auto_increment_offset = 1

default-storage-engine = INNODB
init_connect = 'SET NAMES utf8'
skip-name-resolve

explicit_defaults_for_timestamp = ON

transaction-isolation = REPEATABLE-READ

# [ 扩展设置 ]
key_buffer_size = 16M

# table_open_cache =2000

# show global status like 'sort%';
# show global status like 'Created%';
sort_buffer_size = 4M

join_buffer_size = 2M
read_buffer_size = 4M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 128M
thread_cache_size = 2048
query_cache_limit = 8M
query_cache_min_res_unit = 3k

# show variables like '%query_cache%';
# show status like '%Qcache%';
query_cache_size = 512M
query_cache_type = ON

tmp_table_size = 2G
max_tmp_tables = 256
max_heap_table_size = 96M

bulk_insert_buffer_size = 8M

# [ Galera 参数 ]
wsrep_node_name = abc_01
wsrep_node_address = 192.168.12.69
wsrep_provider = /home/abc/apps/mysql/lib/libgalera_smm.so

wsrep_provider_options = "gcache.size=2G;gcache.page_size=512M;gcs.fc_limit=128;gcs.fc_factor=0.9;gcs.fc_master_slave=YES;gmcast.listen_addr=tcp://0.0.0.0:5551;ist.recv_addr=192.168.12.69:6661;"
wsrep_sst_method = xtrabackup-v2
wsrep_sst_auth = sstuser:s3cretPass
wsrep_sst_receive_address = 192.168.12.69:7771
wsrep_cluster_name = abc
wsrep_slave_threads = 16
wsrep_cluster_address = gcomm://192.168.12.69:5551,192.168.12.70:5551,192.168.12.71:5551

# [ binlog 参数 ]
binlog_format = ROW
log_slave_updates = 1
log-bin = /data/abc/logs/logbin
log-bin-index = /data/abc/logs/logbin.index

# 全局事务id,主从都是5.6才能开启
#enforce_gtid_consistency = 1
#gtid_mode = on

relay-log-index = /data/abc/logs/relaybin.index
relay-log-info-file = /data/abc/logs/relaybin.info
relay-log = /data/abc/logs/relaybin

expire_logs_days = 30

binlog-ignore-db = mysql
binlog-ignore-db = test
binlog-ignore-db = dbsync
binlog-ignore-db = information_schema

replicate-ignore-db = mysql
replicate-ignore-db = test
replicate-ignore-db = dbsync
replicate-ignore-db = information_schema

binlog_cache_size = 64M
max_binlog_size = 128M
max_binlog_cache_size = 1024M
max_relay_log_size = 256M

# [ 慢查询日志 ]
long_query_time = 0.3
log_slow_filter = qc_miss,full_scan,full_join,tmp_table,tmp_table_on_disk,filesort,filesort_on_disk
slow-query-log = 1
log_slow_verbosity = full
log-queries-not-using-indexes = TRUE
log-slow-admin-statements = TRUE
slow_query_log_file = /data/abc/logs/slow.log
log-error = /data/abc/logs/error.log

# [ innodb 相关参数 ]
innodb_data_home_dir = /data/abc/data/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /data/abc/data/
innodb_autoinc_lock_mode = 2

# 为了加速innodb 缓存的预热,关闭mysql时将innodb 缓存数据刷到磁盘
# 启动的时候再从磁盘载入到内存
innodb_buffer_pool_dump_at_shutdown = 1
innodb_buffer_pool_load_at_startup = 1

# 每个表独立文件
innodb_file_per_table = 1

innodb_support_xa = 0
innodb_status_file = 1

# Innodb_buffer_pool_pages_data/Innodb_buffer_pool_pages_total * 100% <90%
innodb_buffer_pool_size = 20G

innodb_log_buffer_size = 1G
innodb_lock_wait_timeout = 100
innodb_flush_log_at_trx_commit = 0

innodb_flush_method = 'O_DIRECT'
innodb_file_io_threads = 4
innodb_thread_concurrency = 16
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 85

# 5.6.5 新增参数,默认是1
# 当刷新一个脏页时,InnoDB存储引擎会检测该页
# 在区(extent)的所有页,如果是脏页,那么一起
# 进行刷新.
innodb_flush_neighbors =1

[mysqldump]
quick
max_allowed_packet = 128M

Revision history for this message
cooper (zyq916) wrote :

CentOS release 5.9 (Final) 2.6.18-348.el5 x86_64
CPU: E5-2630X2
MEM:64G

information type: Private Security → Public
Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

@Cooper,

Thanks for the report. Can you provide full error log, backtrace if possible.

Revision history for this message
cooper (zyq916) wrote :

Thank you for your reply !

backtrace information below:

# resolve_stack_dump -s /tmp/mysqld.sym -n /tmp/mysqld.stack | c++filt
0x8fef15 my_print_stacktrace + 53
0x67cc44 handle_fatal_signal + 1220
0x3551a0eca0 _end + 1349071448
0x3550e302c5 _end + 1336625277
0x3550e31d70 _end + 1336632104
0x948018 lock_print_info_summary(_IO_FILE*, unsigned long) + 600
0x9d7edc srv_printf_innodb_monitor(_IO_FILE*, unsigned long, unsigned long*, unsigned long*) + 588
0x9d8d62 srv_monitor_thread + 786
0x3551a0683d _end + 1349037557
0x3550ed503d _end + 1337300469

Revision history for this message
cooper (zyq916) wrote :

full error log

Revision history for this message
h0rjulf (h0rjulf) wrote :
Download full text (3.2 KiB)

Ubuntu 14.04
Linux 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
mysql Ver 14.14 Distrib 5.6.19-67.0, for debian-linux-gnu (x86_64) using EditLine wrapper

2014-08-28 12:42:52 7f69dc4f2700 InnoDB: Assertion failure in thread 140092644468480 in file lock0lock.cc line 3980
InnoDB: Failing assertion: lock != ctx->wait_lock

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=18
max_threads=502
thread_count=25
connection_count=8
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 208561 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f6ab3ae2a40
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...
stack_bottom = 7f69dc4f1e00 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x7f6aae4b904c]
/usr/sbin/mysqld(handle_fatal_signal+0x3cb)[0x7f6aae1ffa2b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f6aac6aa340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x7f6aabaeaf79]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f6aabaee388]
/usr/sbin/mysqld(+0x7ee8aa)[0x7f6aae56d8aa]
/usr/sbin/mysqld(+0x7f7107)[0x7f6aae576107]
/usr/sbin/mysqld(+0x7f869f)[0x7f6aae57769f]
/usr/sbin/mysqld(+0x7f91bd)[0x7f6aae5781bd]
/usr/sbin/mysqld(+0x7f9e4c)[0x7f6aae578e4c]
/usr/sbin/mysqld(+0x363c1d)[0x7f6aae0e2c1d]
/usr/sbin/mysqld(+0x8750e8)[0x7f6aae5f40e8]
/usr/sbin/mysqld(+0x7c1e8c)[0x7f6aae540e8c]
/usr/sbin/mysqld(_ZN7handler16read_range_firstEPK12st_key_rangeS2_bb+0x2a8)[0x7f6aae129818]
/usr/sbin/mysqld(_ZN7handler21multi_range_read_nextEPPc+0x86)[0x7f6aae127fe6]
/usr/sbin/mysqld(_ZN18QUICK_RANGE_SELECT8get_nextEv+0x4b)[0x7f6aae3b311b]
/usr/sbin/mysqld(+0x65b0cd)[0x7f6aae3da0cd]
/usr/sbin/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0xe61)[0x7f6aae30c2c1]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0xfad)[0x7f6aae29150d]
/usr/sbin/mysqld(+0x519ee8)[0x7f6aae298ee8]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1280)[0x7f6aae29a680]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x16c)[0x7f6aae29c8fc]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x31d)[0x7f6aae25dd3d]
/usr/sbin/mysqld(handle_one_connection+0x40)[0x7f6aae25dde0]
/usr/sbin/mysqld(pfs_spawn_thread+0x140)[0x7f6aae731fb0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f6aac6a2182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6aabbaf30d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f6a6c0334a0): is an invalid pointer
Connection ID (thread ID): 2984679
Status: NOT_KILLED

You may download the Percona XtraDB Cluster operations manual by visiting
http://www.percona.com/software/percona-xtradb-cluster/. You may find information
in the manual which will help you identify the cause of the crash.
140828 12:42:52 mysqld_safe Number of processes running now: 0
140828 12:42:52 mysqld_safe WSREP: not restarting wsrep node automatically
140828 12:42:52 mysqld_safe mysqld from pid file /var/...

Read more...

Revision history for this message
infernix (infernix) wrote :
Download full text (4.2 KiB)

I've gotten this assertion failure as well on a 3-node config:

2014-08-27 12:29:31 10938 [Warning] WSREP: Ignoring error for TO isolated action: source: eca5bcc5-2d2f-11e4-8f7e-0f8a990eca4c version: 3 local: 0 state: APPLYING flags: 65 conn_id: 13012 trx_id: -1 seqnos (l: 656, g: 498, s: 497, d: 497, ts: 79063041752262)
2014-08-27 13:23:21 7fe702492700 InnoDB: Assertion failure in thread 140630152521472 in file lock0lock.cc line 3980
InnoDB: Failing assertion: lock != ctx->wait_lock
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:23:21 UTC - mysqld got signal 6 ;
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.
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.
Please help us make Percona XtraDB Cluster better by reporting any
bugs at https://bugs.launchpad.net/percona-xtradb-cluster

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=6
max_threads=102
thread_count=9
connection_count=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 57084 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7fe6f8338ee0
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...
stack_bottom = 7fe702491e50 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x8c646e]
/usr/sbin/mysqld(handle_fatal_signal+0x379)[0x67f7c9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x7fe7b490f030]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fe7b2b2a545]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x180)[0x7fe7b2b2d7c0]
/usr/sbin/mysqld[0x92053f]
/usr/sbin/mysqld[0x9219c3]
/usr/sbin/mysqld[0x921e6b]
/usr/sbin/mysqld[0x925bd1]
/usr/sbin/mysqld[0x9986df]
/usr/sbin/mysqld[0x99d2bd]
/usr/sbin/mysqld[0x8f2961]
/usr/sbin/mysqld(_ZN7handler17ha_index_read_mapEPhPKhm16ha_rkey_function+0x7f)[0x5de5bf]
/usr/sbin/mysqld(_ZN7handler16read_range_firstEPK12st_key_rangeS2_bb+0xdb)[0x5debfb]
/usr/sbin/mysqld(_ZN7handler21multi_range_read_nextEPPc+0x86)[0x5da716]
/usr/sbin/mysqld(_ZN18QUICK_RANGE_SELECT8get_nextEv+0x52)[0x7ed582]
/usr/sbin/mysqld[0x80ca69]
/usr/sbin/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x11a2)[0x75b3a2]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x1e69)[0x6f5dd9]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x5c8)[0x6f9ad8]
/usr/sbin/mysqld[0x6f9bdd]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3T...

Read more...

Revision history for this message
Krastio Neshev (krastio) wrote :
Download full text (4.0 KiB)

2014-09-30 12:44:32 7f60fc2d6700 InnoDB: Assertion failure in thread 140054524421888 in file lock0lock.cc line 3980
InnoDB: Failing assertion: lock != ctx->wait_lock
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:44:32 UTC - mysqld got signal 6 ;
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.
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.
Please help us make Percona XtraDB Cluster better by reporting any
bugs at https://bugs.launchpad.net/percona-xtradb-cluster

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=21
max_threads=202
thread_count=8
connection_count=6
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 97010 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x1e566760
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...
stack_bottom = 7f60fc2d5d30 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0x8fa26b]
/usr/sbin/mysqld(handle_fatal_signal+0x471)[0x673f21]
/usr/lib64/libpthread.so.0(+0xf130)[0x7f612cb3c130]
/usr/lib64/libc.so.6(gsignal+0x39)[0x7f612aed65c9]
/usr/lib64/libc.so.6(abort+0x148)[0x7f612aed7cd8]
/usr/sbin/mysqld[0x9940fa]
/usr/sbin/mysqld[0x99cc71]
/usr/sbin/mysqld[0x99e368]
/usr/sbin/mysqld[0x99eecd]
/usr/sbin/mysqld[0x99fc1c]
/usr/sbin/mysqld[0x9fc043]
/usr/sbin/mysqld[0x9fc4dd]
/usr/sbin/mysqld[0x9fcb24]
/usr/sbin/mysqld[0xa07bf7]
/usr/sbin/mysqld[0x96be37]
/usr/sbin/mysqld(_ZN7handler12ha_write_rowEPh+0x10f)[0x5b96af]
/usr/sbin/mysqld(_Z12write_recordP3THDP5TABLEP9COPY_INFOS4_+0x215)[0x6e0dc5]
/usr/sbin/mysqld(_Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesb+0x10a1)[0x6e6881]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x2e30)[0x6fa870]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x5e8)[0x6ffd78]
/usr/sbin/mysqld[0x7005c8]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x11fa)[0x701e1a]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x18f)[0x703fef]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x182)[0x6cd072]
/usr/sbin/mysqld(handle_one_connection+0x40)[0x6cd260]
/usr/sbin/mysqld(pfs_spawn_thread+0x143)[0x9327d3]
/usr/lib64/libpthread.so.0(+0x7df3)[0x7f612cb34df3]
/usr/lib64/libc.so.6(clone+0x6d)[0x7f612af9701d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f60d8066fd0): is an invalid pointer
Conn...

Read more...

Revision history for this message
infernix (infernix) wrote :
Download full text (3.8 KiB)

Todays crash:

2014-10-10 12:23:14 7ff53c106700 InnoDB: Assertion failure in thread 140691251422976 in file lock0lock.cc line 3980
InnoDB: Failing assertion: lock != ctx->wait_lock
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:23:14 UTC - mysqld got signal 6 ;
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.
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.
Please help us make Percona XtraDB Cluster better by reporting any
bugs at https://bugs.launchpad.net/percona-xtradb-cluster

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=5
max_threads=402
thread_count=8
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 176839 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7ff53816aa50
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...
stack_bottom = 7ff53c105e50 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x8c8e1e]
/usr/sbin/mysqld(handle_fatal_signal+0x36c)[0x680ffc]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x7ff5dfcef030]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7ff5ddf0a545]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x180)[0x7ff5ddf0d7c0]
/usr/sbin/mysqld[0x922d1f]
/usr/sbin/mysqld[0x9241a3]
/usr/sbin/mysqld[0x92464b]
/usr/sbin/mysqld[0x9283b1]
/usr/sbin/mysqld[0x99bcff]
/usr/sbin/mysqld[0x9a088d]
/usr/sbin/mysqld[0x8f5331]
/usr/sbin/mysqld(_ZN7handler17ha_index_read_mapEPhPKhm16ha_rkey_function+0x7f)[0x5dfb0f]
/usr/sbin/mysqld(_ZN7handler16read_range_firstEPK12st_key_rangeS2_bb+0xdb)[0x5e014b]
/usr/sbin/mysqld(_ZN7handler21multi_range_read_nextEPPc+0x86)[0x5dbed6]
/usr/sbin/mysqld(_ZN18QUICK_RANGE_SELECT8get_nextEv+0x52)[0x7efc72]
/usr/sbin/mysqld[0x80f599]
/usr/sbin/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x11a2)[0x75d822]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x1cfa)[0x6f7b9a]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x588)[0x6fbbb8]
/usr/sbin/mysqld[0x6fbcbd]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xc4e)[0x6fcdbe]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x1f1)[0x6fde21]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x27d)[0x6cf8ed]
/usr/sbin/mysqld(handle_one_connection+0x42)[0x6cf972]
/usr/sbin/mysqld(pfs_spawn_thread+0x140)[0xb13270]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x7ff5dfc...

Read more...

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

"lock != ctx->wait_lock" should be fixed in 5.6.21.

Please test with 5.6.21 in CentOS testing.

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-1678

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.