Mysqld signal 11

Bug #1290865 reported by Dennis Ng
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Expired
Undecided
Unassigned
5.6
Expired
Undecided
Unassigned

Bug Description

Hi

I've received a signal 11 from mysqld not sure what the cause it but here is the output

20:30:29 UTC - mysqld got signal 11 ;
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 Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=268435456
read_buffer_size=1048576
max_used_connections=483
max_threads=153
thread_count=439
connection_count=439
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1055679 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x2aafb4622920
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 = 2aaf8d18c088 thread_stack 0x40000
/mnt/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x90e785]
/mnt/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x694d24]
/lib64/libpthread.so.0[0x2b2f35357b10]
/mnt/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x7fcac9]
/mnt/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0x7f)[0x802eff]
/mnt/mysql/bin/mysqld(_ZN10Item_field13save_in_fieldEP5Fieldb+0x4e)[0x5ea5ae]
/mnt/mysql/bin/mysqld(_Z12sp_eval_exprP3THDP5FieldPP4Item+0x7f)[0x69505f]
/mnt/mysql/bin/mysqld(_ZN9sp_cursor24Select_fetch_into_spvars9send_dataER4ListI4ItemE+0x5b)[0x69f9bb]
/mnt/mysql/bin/mysqld(_ZN19Materialized_cursor5fetchEm+0x4d)[0x6e840d]
/mnt/mysql/bin/mysqld(_ZN9sp_cursor5fetchEP3THDP4ListI11sp_variableE+0xcf)[0x69f6bf]
/mnt/mysql/bin/mysqld(_ZN7sp_head7executeEP3THDb+0x702)[0x69b1a2]
/mnt/mysql/bin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x6d7)[0x69c5a7]
/mnt/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x13f8)[0x7158d8]
/mnt/mysql/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x608)[0x719a28]
/mnt/mysql/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x146f)[0x71aeff]
/mnt/mysql/bin/mysqld(_Z24do_handle_one_connectionP3THD+0x16f)[0x6e7dff]
/mnt/mysql/bin/mysqld(handle_one_connection+0x47)[0x6e7ed7]
/mnt/mysql/bin/mysqld(pfs_spawn_thread+0x12a)[0xb4cb8a]
/lib64/libpthread.so.0[0x2b2f3534f73d]
/lib64/libc.so.6(clone+0x6d)[0x2b2f366114bd]

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

You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.
140310 16:30:34 mysqld_safe Number of processes running now: 0
140310 16:30:34 mysqld_safe mysqld restarted

Here is my.cnf

# Example MySQL config file for large systems.
#
# This is for a large system with memory = 512M where the system runs mainly
# MySQL.
#
# MySQL programs look for option files in a set of
# locations which depend on the deployment platform.
# You can copy this option file to one of those
# locations. For information about these locations, see:
# http://dev.mysql.com/doc/mysql/en/option-files.html
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--help" option.

# The following options will be passed to all MySQL clients
[client]
#password = your_password
port = 3306
socket = /tmp/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port = 3306
socket = /tmp/mysql.sock
basedir = /mnt/mysql
datadir = /mnt/mysql/data
skip-external-locking
key_buffer_size = 16M
max_allowed_packet = 1M
table_open_cache = 256
sort_buffer_size = 4M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 32

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking

# Replication Master Server (default)
# binary logging is required for replication
log-bin=/u01/binlog/10-231-139-135-bin

# binary logging format - mixed recommended
binlog_format=row
binlog_checksum=none

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server_id = 1

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
# the syntax is:
#
# CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
# MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
# where you replace <host>, <user>, <password> by quoted strings and
# <port> by the master's port number (3306 by default).
#
# Example:
#
# CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
# MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
# start replication for the first time (even unsuccessfully, for example
# if you mistyped the password in master-password and the slave fails to
# connect), the slave will create a master.info file, and any later
# change in this file to the variables' values below will be ignored and
# overridden by the content of the master.info file, unless you shutdown
# the slave server, delete master.info and restart the slaver server.
# For that reason, you may want to leave the lines below untouched
# (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id = 2
#
# The replication master for this slave - required
#master-host = <hostname>
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user = <username>
#
# The password the slave will authenticate with when connecting to
# the master - required
#master-password = <password>
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port = <port>
#
# binary logging - not required for slaves, but recommended
#log-bin=mysql-bin

# Uncomment the following if you are using InnoDB tables
innodb_data_home_dir = /mnt/mysql/data
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /mnt/mysql/data
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 18G
innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 720M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
innodb_write_io_threads = 64
innodb_read_io_threads = 64
innodb_flush_method = O_DIRECT

#SSL configured parameters
ssl
ssl-cipher=DHE-RSA-AES256-SHA
ssl-ca=/mnt/newcerts/ca-cert.pem
ssl-cert=/mnt/newcerts/server-cert.pem
ssl-key=/mnt/newcerts/server-key.pem

#2014-03-06 added by dng
log_bin_trust_function_creators = 1

#2014-03-10 added by dng
sync_binlog = 1
slave_parallel_workers = 4
max_connections = 800

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[myisamchk]
key_buffer_size = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

[client]

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

Thank you for the bug report.

What exact Percona Server version, 5.x.y, is it? It seems crash happened while some stored procedure was executed. Are you able to identify what exact procedure caused it, from the binary log maybe?

Changed in percona-server:
status: New → Incomplete
Revision history for this message
Dennis Ng (dng) wrote : Re: [Bug 1290865] Re: Mysqld signal 11
Download full text (10.0 KiB)

Hi Valerii

Thanks for you response,
I'm Percona-Server-5.6.15-rel63.0-519-static-openssl-1.0.1e.Linux.x86_64
version. Unfortunately our applications has a large amount of stored
procedures so it will take some time to find out which one.

Dennis

On Tue, Mar 11, 2014 at 9:34 AM, Valerii Kravchuk <
<email address hidden>> wrote:

> Thank you for the bug report.
>
> What exact Percona Server version, 5.x.y, is it? It seems crash happened
> while some stored procedure was executed. Are you able to identify what
> exact procedure caused it, from the binary log maybe?
>
> ** Changed in: percona-server
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1290865
>
> Title:
> Mysqld signal 11
>
> Status in Percona Server with XtraDB:
> Incomplete
>
> Bug description:
> Hi
>
> I've received a signal 11 from mysqld not sure what the cause it but
> here is the output
>
> 20:30:29 UTC - mysqld got signal 11 ;
> 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 Server better by reporting any
> bugs at http://bugs.percona.com/
>
> key_buffer_size=268435456
> read_buffer_size=1048576
> max_used_connections=483
> max_threads=153
> thread_count=439
> connection_count=439
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 1055679 K bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> Thread pointer: 0x2aafb4622920
> 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 = 2aaf8d18c088 thread_stack 0x40000
> /mnt/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x90e785]
> /mnt/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x694d24]
> /lib64/libpthread.so.0[0x2b2f35357b10]
> /mnt/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x7fcac9]
> /mnt/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0x7f)[0x802eff]
>
> /mnt/mysql/bin/mysqld(_ZN10Item_field13save_in_fieldEP5Fieldb+0x4e)[0x5ea5ae]
> /mnt/mysql/bin/mysqld(_Z12sp_eval_exprP3THDP5FieldPP4Item+0x7f)[0x69505f]
>
> /mnt/mysql/bin/mysqld(_ZN9sp_cursor24Select_fetch_into_spvars9send_dataER4ListI4ItemE+0x5b)[0x69f9bb]
> /mnt/mysql/bin/mysqld(_ZN19Materialized_cursor5fetchEm+0x4d)[0x6e840d]
>
> /mnt/mysql/bin/mysqld(_ZN9sp_cursor5fetchEP3THDP4ListI11sp_variableE+0xcf)[0x69f6bf]
> /mnt/mysql/bin/mysqld(_ZN7sp_head7executeEP3THDb+0x702)[0x69b1a2]
>
> /mnt/mysql/bin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x6d7)[0x69c5a7]
> /mnt/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x13f8)[0x7158d8]
>
> /mnt/mysql/bin/mys...

Revision history for this message
Dennis Ng (dng) wrote :
Download full text (10.5 KiB)

Hi Valerii

As from the binlog unfortunately the instance terminated before it could
log the stored procedure into the binlog. Is there a quick way I could
identify the store procedure

Dennis

On Tue, Mar 11, 2014 at 9:49 AM, Dennis Ng <email address hidden> wrote:

> Hi Valerii
>
> Thanks for you response,
> I'm Percona-Server-5.6.15-rel63.0-519-static-openssl-1.0.1e.Linux.x86_64
> version. Unfortunately our applications has a large amount of stored
> procedures so it will take some time to find out which one.
>
> Dennis
>
>
>
> On Tue, Mar 11, 2014 at 9:34 AM, Valerii Kravchuk <
> <email address hidden>> wrote:
>
>> Thank you for the bug report.
>>
>> What exact Percona Server version, 5.x.y, is it? It seems crash happened
>> while some stored procedure was executed. Are you able to identify what
>> exact procedure caused it, from the binary log maybe?
>>
>> ** Changed in: percona-server
>> Status: New => Incomplete
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1290865
>>
>> Title:
>> Mysqld signal 11
>>
>> Status in Percona Server with XtraDB:
>> Incomplete
>>
>> Bug description:
>> Hi
>>
>> I've received a signal 11 from mysqld not sure what the cause it but
>> here is the output
>>
>> 20:30:29 UTC - mysqld got signal 11 ;
>> 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 Server better by reporting any
>> bugs at http://bugs.percona.com/
>>
>> key_buffer_size=268435456
>> read_buffer_size=1048576
>> max_used_connections=483
>> max_threads=153
>> thread_count=439
>> connection_count=439
>> It is possible that mysqld could use up to
>> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
>> 1055679 K bytes of memory
>> Hope that's ok; if not, decrease some variables in the equation.
>>
>> Thread pointer: 0x2aafb4622920
>> 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 = 2aaf8d18c088 thread_stack 0x40000
>> /mnt/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x90e785]
>> /mnt/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x694d24]
>> /lib64/libpthread.so.0[0x2b2f35357b10]
>> /mnt/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x7fcac9]
>> /mnt/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0x7f)[0x802eff]
>>
>> /mnt/mysql/bin/mysqld(_ZN10Item_field13save_in_fieldEP5Fieldb+0x4e)[0x5ea5ae]
>>
>> /mnt/mysql/bin/mysqld(_Z12sp_eval_exprP3THDP5FieldPP4Item+0x7f)[0x69505f]
>>
>> /mnt/mysql/bin/mysqld(_ZN9sp_cursor24Select_fetch_into_spvars9send_dataER4ListI4ItemE+0x5b)[0x69f9bb]
>> /mnt/mysql/bin/mysqld(_ZN19Materialized_cursor5fetchEm+0x4...

Revision history for this message
Dennis Ng (dng) wrote :
Download full text (9.9 KiB)

Hi Valerii

Has anyone mentioned problems with running the Mysql Enterprise Monitor
mysql-monitor-agent with Percona. I shutdown the agent right around the
time of the 3rd crash this morning and after that I have not had a crash
since.

Dennis

On Tue, Mar 11, 2014 at 10:02 AM, Valerii Kravchuk <
<email address hidden>> wrote:

> ** Also affects: percona-server/5.6
> Importance: Undecided
> Status: Incomplete
>
> ** Changed in: percona-server/5.6
> Status: Incomplete => New
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1290865
>
> Title:
> Mysqld signal 11
>
> Status in Percona Server with XtraDB:
> New
> Status in Percona Server 5.6 series:
> New
>
> Bug description:
> Hi
>
> I've received a signal 11 from mysqld not sure what the cause it but
> here is the output
>
> 20:30:29 UTC - mysqld got signal 11 ;
> 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 Server better by reporting any
> bugs at http://bugs.percona.com/
>
> key_buffer_size=268435456
> read_buffer_size=1048576
> max_used_connections=483
> max_threads=153
> thread_count=439
> connection_count=439
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 1055679 K bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> Thread pointer: 0x2aafb4622920
> 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 = 2aaf8d18c088 thread_stack 0x40000
> /mnt/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x90e785]
> /mnt/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x694d24]
> /lib64/libpthread.so.0[0x2b2f35357b10]
> /mnt/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x7fcac9]
> /mnt/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0x7f)[0x802eff]
>
> /mnt/mysql/bin/mysqld(_ZN10Item_field13save_in_fieldEP5Fieldb+0x4e)[0x5ea5ae]
> /mnt/mysql/bin/mysqld(_Z12sp_eval_exprP3THDP5FieldPP4Item+0x7f)[0x69505f]
>
> /mnt/mysql/bin/mysqld(_ZN9sp_cursor24Select_fetch_into_spvars9send_dataER4ListI4ItemE+0x5b)[0x69f9bb]
> /mnt/mysql/bin/mysqld(_ZN19Materialized_cursor5fetchEm+0x4d)[0x6e840d]
>
> /mnt/mysql/bin/mysqld(_ZN9sp_cursor5fetchEP3THDP4ListI11sp_variableE+0xcf)[0x69f6bf]
> /mnt/mysql/bin/mysqld(_ZN7sp_head7executeEP3THDb+0x702)[0x69b1a2]
>
> /mnt/mysql/bin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x6d7)[0x69c5a7]
> /mnt/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x13f8)[0x7158d8]
>
> /mnt/mysql/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x608)[0x719a28]
>
> /mnt/mysql/bin/mysqld(_Z16dispatch_comman...

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

As for MEM's agent, I remember that it was probably running some "wrong" queries against information_schema (in some versions) that could lead to crash, but this your crash is different. It probably could case some extra memory use or even memory leaks.

Anyway, what exact MEM version do you have?

As you have ROW logging into the binary log, hardly you can expect to see CALL to procedure logged there even in case of success. I just wondered if the content of the binary log before the crash could give you any hint on what kind of "operation" could be involved in that crash.

Revision history for this message
Dennis Ng (dng) wrote :
Download full text (10.2 KiB)

Hi Valerii

I was running MySQL Monitor version 3.0.6. I check the different binlogs
to see if there is any pattern.

Dennis

On Tue, Mar 11, 2014 at 10:45 AM, Valerii Kravchuk <
<email address hidden>> wrote:

> As for MEM's agent, I remember that it was probably running some "wrong"
> queries against information_schema (in some versions) that could lead to
> crash, but this your crash is different. It probably could case some
> extra memory use or even memory leaks.
>
> Anyway, what exact MEM version do you have?
>
> As you have ROW logging into the binary log, hardly you can expect to
> see CALL to procedure logged there even in case of success. I just
> wondered if the content of the binary log before the crash could give
> you any hint on what kind of "operation" could be involved in that
> crash.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1290865
>
> Title:
> Mysqld signal 11
>
> Status in Percona Server with XtraDB:
> New
> Status in Percona Server 5.6 series:
> New
>
> Bug description:
> Hi
>
> I've received a signal 11 from mysqld not sure what the cause it but
> here is the output
>
> 20:30:29 UTC - mysqld got signal 11 ;
> 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 Server better by reporting any
> bugs at http://bugs.percona.com/
>
> key_buffer_size=268435456
> read_buffer_size=1048576
> max_used_connections=483
> max_threads=153
> thread_count=439
> connection_count=439
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 1055679 K bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> Thread pointer: 0x2aafb4622920
> 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 = 2aaf8d18c088 thread_stack 0x40000
> /mnt/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x90e785]
> /mnt/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x694d24]
> /lib64/libpthread.so.0[0x2b2f35357b10]
> /mnt/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x7fcac9]
> /mnt/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0x7f)[0x802eff]
>
> /mnt/mysql/bin/mysqld(_ZN10Item_field13save_in_fieldEP5Fieldb+0x4e)[0x5ea5ae]
> /mnt/mysql/bin/mysqld(_Z12sp_eval_exprP3THDP5FieldPP4Item+0x7f)[0x69505f]
>
> /mnt/mysql/bin/mysqld(_ZN9sp_cursor24Select_fetch_into_spvars9send_dataER4ListI4ItemE+0x5b)[0x69f9bb]
> /mnt/mysql/bin/mysqld(_ZN19Materialized_cursor5fetchEm+0x4d)[0x6e840d]
>
> /mnt/mysql/bin/mysqld(_ZN9sp_cursor5fetchEP3THDP4ListI11sp_variableE+0xcf)[0x69f6bf]
> /mnt/mysql/bin/mysqld(_ZN7sp_head7executeEP...

Revision history for this message
Dennis Ng (dng) wrote :
Download full text (10.9 KiB)

Hi Valerii

I've disabled the agent and the database seems to be stable. I've looked
at the binlogs and noticed that just before it crashed that it was running
code from a few procedures that use cursors to insert/delete data for other
tables, the stack trace seems to point that out as well. Will you keep you
posted.

Dennis

On Tue, Mar 11, 2014 at 10:53 AM, Dennis Ng <email address hidden> wrote:

> Hi Valerii
>
> I was running MySQL Monitor version 3.0.6. I check the different binlogs
> to see if there is any pattern.
>
> Dennis
>
>
> On Tue, Mar 11, 2014 at 10:45 AM, Valerii Kravchuk <
> <email address hidden>> wrote:
>
>> As for MEM's agent, I remember that it was probably running some "wrong"
>> queries against information_schema (in some versions) that could lead to
>> crash, but this your crash is different. It probably could case some
>> extra memory use or even memory leaks.
>>
>> Anyway, what exact MEM version do you have?
>>
>> As you have ROW logging into the binary log, hardly you can expect to
>> see CALL to procedure logged there even in case of success. I just
>> wondered if the content of the binary log before the crash could give
>> you any hint on what kind of "operation" could be involved in that
>> crash.
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1290865
>>
>> Title:
>> Mysqld signal 11
>>
>> Status in Percona Server with XtraDB:
>> New
>> Status in Percona Server 5.6 series:
>> New
>>
>> Bug description:
>> Hi
>>
>> I've received a signal 11 from mysqld not sure what the cause it but
>> here is the output
>>
>> 20:30:29 UTC - mysqld got signal 11 ;
>> 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 Server better by reporting any
>> bugs at http://bugs.percona.com/
>>
>> key_buffer_size=268435456
>> read_buffer_size=1048576
>> max_used_connections=483
>> max_threads=153
>> thread_count=439
>> connection_count=439
>> It is possible that mysqld could use up to
>> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
>> 1055679 K bytes of memory
>> Hope that's ok; if not, decrease some variables in the equation.
>>
>> Thread pointer: 0x2aafb4622920
>> 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 = 2aaf8d18c088 thread_stack 0x40000
>> /mnt/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x90e785]
>> /mnt/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x694d24]
>> /lib64/libpthread.so.0[0x2b2f35357b10]
>> /mnt/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x7fcac9]
>> /mnt/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0...

Revision history for this message
Dennis Ng (dng) wrote :
Download full text (18.1 KiB)

Hi Valerii

I think I've pinpointed the problem here are my findings. I inherited this
legacy code so it took some time for me to find it.

STACK TRACE FROM TODAY
19:17:11 UTC - mysqld got signal 11 ;
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 Server better by reporting any
bugs at http://bugs.percona.com/

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

Thread pointer: 0x2aaf902c9480
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 = 411cc0b8 thread_stack 0x40000
/mnt/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x90e785]
/mnt/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x694d24]
/lib64/libpthread.so.0[0x2ae4c15c6b10]
/mnt/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x7fcac9]
/mnt/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0x7f)[0x802eff]
/mnt/mysql/bin/mysqld(_ZN10Item_field13save_in_fieldEP5Fieldb+0x4e)[0x5ea5ae]
/mnt/mysql/bin/mysqld(_Z12sp_eval_exprP3THDP5FieldPP4Item+0x7f)[0x69505f]
/mnt/mysql/bin/mysqld(_ZN9sp_cursor24Select_fetch_into_spvars9send_dataER4ListI4ItemE+0x5b)[0x69f9bb]
/mnt/mysql/bin/mysqld(_ZN19Materialized_cursor5fetchEm+0x4d)[0x6e840d]
/mnt/mysql/bin/mysqld(_ZN9sp_cursor5fetchEP3THDP4ListI11sp_variableE+0xcf)[0x69f6bf]
/mnt/mysql/bin/mysqld(_ZN7sp_head7executeEP3THDb+0x702)[0x69b1a2]
/mnt/mysql/bin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x6d7)[0x69c5a7]
/mnt/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x13f8)[0x7158d8]
/mnt/mysql/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x608)[0x719a28]
/mnt/mysql/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x146f)[0x71aeff]
/mnt/mysql/bin/mysqld(_Z24do_handle_one_connectionP3THD+0x16f)[0x6e7dff]
/mnt/mysql/bin/mysqld(handle_one_connection+0x47)[0x6e7ed7]
/lib64/libpthread.so.0[0x2ae4c15be73d]
/lib64/libc.so.6(clone+0x6d)[0x2ae4c28804bd]

LAST LOG MESSAGES FROM BINLOG BEFORE THE CRASH

/*!*/;
# at 199406
#140312 15:17:11 server id 1 end_log_pos 199469 Table_map:
`roseman`.`temp_Appointment` mapped to number 89
# at 199469
#140312 15:17:11 server id 1 end_log_pos 199546 Write_rows: table id 89
flags: STMT_END_F
### INSERT INTO `roseman`.`temp_Appointment`
### SET
### @1=13047
### @2=31
### @3=0
### @4='D2591A4ACC67C23E582FEC70DF2EC5EC'
# at 199546
#140312 15:17:11 server id 1 end_log_pos 199573 Xid = 6386198
COMMIT/*!*/;
# at 199573
#140312 15:17:11 server id 1 end_log_pos 199646 Query thread_id=31
exec_time=0 error_code=0
SET TIMESTAMP=1394651831/...

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

Please, send the output of:

show create table roseman.`temp_Appointment`\G

Can you also send the entire code of the stored procedure where that INSERT comes from?

Revision history for this message
Dennis Ng (dng) wrote :
Download full text (9.9 KiB)

Hi Valerii

Here's the information that you requested but I think the issue lies in the
fetch into cursor which is what the trace is eluding too.

Dennis

On Thu, Mar 13, 2014 at 5:38 AM, Valerii Kravchuk <
<email address hidden>> wrote:

> Please, send the output of:
>
> show create table roseman.`temp_Appointment`\G
>
> Can you also send the entire code of the stored procedure where that
> INSERT comes from?
>
> ** Changed in: percona-server/5.6
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1290865
>
> Title:
> Mysqld signal 11
>
> Status in Percona Server with XtraDB:
> Incomplete
> Status in Percona Server 5.6 series:
> Incomplete
>
> Bug description:
> Hi
>
> I've received a signal 11 from mysqld not sure what the cause it but
> here is the output
>
> 20:30:29 UTC - mysqld got signal 11 ;
> 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 Server better by reporting any
> bugs at http://bugs.percona.com/
>
> key_buffer_size=268435456
> read_buffer_size=1048576
> max_used_connections=483
> max_threads=153
> thread_count=439
> connection_count=439
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 1055679 K bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> Thread pointer: 0x2aafb4622920
> 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 = 2aaf8d18c088 thread_stack 0x40000
> /mnt/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x90e785]
> /mnt/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x694d24]
> /lib64/libpthread.so.0[0x2b2f35357b10]
> /mnt/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x7fcac9]
> /mnt/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0x7f)[0x802eff]
>
> /mnt/mysql/bin/mysqld(_ZN10Item_field13save_in_fieldEP5Fieldb+0x4e)[0x5ea5ae]
> /mnt/mysql/bin/mysqld(_Z12sp_eval_exprP3THDP5FieldPP4Item+0x7f)[0x69505f]
>
> /mnt/mysql/bin/mysqld(_ZN9sp_cursor24Select_fetch_into_spvars9send_dataER4ListI4ItemE+0x5b)[0x69f9bb]
> /mnt/mysql/bin/mysqld(_ZN19Materialized_cursor5fetchEm+0x4d)[0x6e840d]
>
> /mnt/mysql/bin/mysqld(_ZN9sp_cursor5fetchEP3THDP4ListI11sp_variableE+0xcf)[0x69f6bf]
> /mnt/mysql/bin/mysqld(_ZN7sp_head7executeEP3THDb+0x702)[0x69b1a2]
>
> /mnt/mysql/bin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x6d7)[0x69c5a7]
> /mnt/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x13f8)[0x7158d8]
>
> /mnt/mysql/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x608)[0x719a28]
>
> /mnt/mysql/bin/mysqld(_Z16dispatch_co...

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

Assuming that you are right about fetch, I wonder how appoAppointmentResources.appoPositions column is defined in the table. This is the only string column in that cursor.

Please, send the output of:

show create table appoAppointmentResources\G

Revision history for this message
Dennis Ng (dng) wrote :
Download full text (10.6 KiB)

Hi Valerii

Here's the show create table

mysql> show create table appoAppointmentResources\G
*************************** 1. row ***************************
       Table: appoAppointmentResources
Create Table: CREATE TABLE `appoAppointmentResources` (
  `appoHdrID` bigint(20) NOT NULL,
  `dtlID` int(11) NOT NULL,
  `pracResourceID` int(11) DEFAULT NULL,
  `pracProviderID` int(11) DEFAULT NULL,
  `appoPositions` char(5) COLLATE utf8_bin NOT NULL DEFAULT 'F',
  PRIMARY KEY (`appoHdrID`,`dtlID`),
  CONSTRAINT `FK_appoAppointmentResources_1` FOREIGN KEY (`appoHdrID`)
REFERENCES `appoAppointmentProcedureSteps` (`appoHdrID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

The only thing is see is appoPosition is CHAR(5) while in the stored
procedure it was specified as a varchar(10)

Dennis

On Fri, Mar 14, 2014 at 6:52 AM, Valerii Kravchuk <
<email address hidden>> wrote:

> Assuming that you are right about fetch, I wonder how
> appoAppointmentResources.appoPositions column is defined in the table.
> This is the only string column in that cursor.
>
> Please, send the output of:
>
> show create table appoAppointmentResources\G
>
> ** Changed in: percona-server/5.6
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1290865
>
> Title:
> Mysqld signal 11
>
> Status in Percona Server with XtraDB:
> Incomplete
> Status in Percona Server 5.6 series:
> Incomplete
>
> Bug description:
> Hi
>
> I've received a signal 11 from mysqld not sure what the cause it but
> here is the output
>
> 20:30:29 UTC - mysqld got signal 11 ;
> 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 Server better by reporting any
> bugs at http://bugs.percona.com/
>
> key_buffer_size=268435456
> read_buffer_size=1048576
> max_used_connections=483
> max_threads=153
> thread_count=439
> connection_count=439
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 1055679 K bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> Thread pointer: 0x2aafb4622920
> 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 = 2aaf8d18c088 thread_stack 0x40000
> /mnt/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x90e785]
> /mnt/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x694d24]
> /lib64/libpthread.so.0[0x2b2f35357b10]
> /mnt/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x7fcac9]
> /mnt/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0x7f)[0x802eff]
>
> /mnt/mysql/bin/mysqld(_ZN10Item_field13save_in_fieldEP...

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

Yes, but I see it's utf8 column, so up to 3*5=15 bytes may be needed. Can you, please, check with

show create procedure stp_DecoupledAppointment\G

what character set was effective when procdure was created? If it's not utf8, then we may have a problem here.

Revision history for this message
Dennis Ng (dng) wrote :
Download full text (17.2 KiB)

Hi Valerri

looks like its latin1

mysql> show create procedure stp_DecoupledAppointment\G
*************************** 1. row ***************************
           Procedure: stp_DecoupledAppointment
            sql_mode: NO_ENGINE_SUBSTITUTION
    Create Procedure: CREATE DEFINER=`ice`@`10.%` PROCEDURE
`stp_DecoupledAppointment`(
v_appoDate DATE,
v_sessionID VARCHAR(100)
)
BEGIN
DECLARE actual_row_number INTEGER DEFAULT 0;
DECLARE numRows INTEGER DEFAULT 0;
DECLARE done INT DEFAULT 0;
DECLARE v_hdrID INT DEFAULT 0;
DECLARE v_appoProcExpStartTime DATETIME;
DECLARE v_appoProcExpEndTime DATETIME;
DECLARE v_pracProviderID INT DEFAULT 0;
DECLARE v_pracResourceID INT DEFAULT 0;
DECLARE intCount INT DEFAULT 0;
DECLARE v_appoPositions CHAR(5);
DECLARE cur1 CURSOR FOR
SELECT
appoAppointmentHeader.hdrID,
appoAppointmentProcedureSteps.appoProcExpStartTime,
appoAppointmentProcedureSteps.appoProcExpEndTime,
appoAppointmentResources.pracProviderID,
appoAppointmentResources.pracResourceID,
appoAppointmentResources.appoPositions
FROM appoAppointmentHeader
INNER JOIN appoAppointmentProcedureSteps
ON appoAppointmentProcedureSteps.appoHdrID=appoAppointmentHeader.hdrID
INNER JOIN appoAppointmentResources
ON appoAppointmentResources.appoHdrID=appoAppointmentHeader.hdrID
WHERE
appoAppointmentHeader.appoDate=v_appoDate
AND appoAppointmentHeader.currentAppoHdrStatusID NOT IN(100,200)
ORDER BY
TIME_TO_SEC(TIMEDIFF(appoAppointmentProcedureSteps.appoProcExpStartTime,appoAppointmentProcedureSteps.appoProcExpStartTime))
DESC;
DELETE FROM temp_Appointment WHERE temp_Appointment.sessionID=v_sessionID;
OPEN cur1;
SELECT FOUND_ROWS() INTO numRows;
IF numRows>0 THEN
get_form: LOOP
FETCH cur1 INTO
v_hdrID,v_appoProcExpStartTime,v_appoProcExpEndTime,v_pracProviderID,v_pracResourceID,v_appoPositions;

       SELECT COUNT(*) INTO intCount
       FROM
       temp_Appointment
       WHERE
       temp_Appointment.hdrID=v_hdrID
       AND
       temp_Appointment.pracProviderID=v_pracProviderID
       AND
       temp_Appointment.pracResourceID=v_pracResourceID
       AND
       temp_Appointment.sessionID=v_sessionID;

       IF intCount=0 THEN
                SELECT COUNT(*) INTO intCount
                FROM
                appoAppointmentResources
                INNER JOIN appoAppointmentHeader ON
appoAppointmentHeader.hdrID=appoAppointmentResources.appoHdrID
                INNER JOIN appoAppointmentProcedureSteps ON
appoAppointmentProcedureSteps.appoHdrID=appoAppointmentHeader.hdrID
                WHERE
                 appoAppointmentHeader.currentAppoHdrStatusID NOT
IN(100,200)
                 AND
appoAppointmentResources.pracProviderID=v_pracProviderID
                 AND
appoAppointmentResources.pracResourceID=v_pracResourceID
                AND appoAppointmentHeader.appoDate = appoDate
                AND appoAppointmentHeader.hdrID<>v_hdrID
AND
(
(DATE_ADD(v_appoProcExpStartTime,INTERVAL 1 SECOND) BETWEEN
 appoProcExpStartTime AND appoProcExpEndTime
OR
DATE_ADD(v_appoProcExpEndTime,INTERVAL -1 SECOND) BETWEEN
 appoProcExpStartTime AND appoProcExpEndTime)
OR
(
appoProcExpStartTime > v_appoProcExpStartTime
AND
appoProcExpEndTime < v_appoProcExpEndTime
)
);
      ...

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

So, it seems we have to re-create the procedure to either use varchar(5) or char(5) with utf8 charset, or at least varchar(15) to be able to fetch all the data without memory overrun.

Revision history for this message
Dennis Ng (dng) wrote :
Download full text (9.8 KiB)

Hi Valerii

I'll try recompiling it with the utf8 charset and see if that fixes the
problem.

Dennis

On Fri, Mar 14, 2014 at 12:24 PM, Valerii Kravchuk <
<email address hidden>> wrote:

> So, it seems we have to re-create the procedure to either use varchar(5)
> or char(5) with utf8 charset, or at least varchar(15) to be able to
> fetch all the data without memory overrun.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1290865
>
> Title:
> Mysqld signal 11
>
> Status in Percona Server with XtraDB:
> Incomplete
> Status in Percona Server 5.6 series:
> Incomplete
>
> Bug description:
> Hi
>
> I've received a signal 11 from mysqld not sure what the cause it but
> here is the output
>
> 20:30:29 UTC - mysqld got signal 11 ;
> 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 Server better by reporting any
> bugs at http://bugs.percona.com/
>
> key_buffer_size=268435456
> read_buffer_size=1048576
> max_used_connections=483
> max_threads=153
> thread_count=439
> connection_count=439
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 1055679 K bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> Thread pointer: 0x2aafb4622920
> 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 = 2aaf8d18c088 thread_stack 0x40000
> /mnt/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x90e785]
> /mnt/mysql/bin/mysqld(handle_fatal_signal+0x4c4)[0x694d24]
> /lib64/libpthread.so.0[0x2b2f35357b10]
> /mnt/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x7fcac9]
> /mnt/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0x7f)[0x802eff]
>
> /mnt/mysql/bin/mysqld(_ZN10Item_field13save_in_fieldEP5Fieldb+0x4e)[0x5ea5ae]
> /mnt/mysql/bin/mysqld(_Z12sp_eval_exprP3THDP5FieldPP4Item+0x7f)[0x69505f]
>
> /mnt/mysql/bin/mysqld(_ZN9sp_cursor24Select_fetch_into_spvars9send_dataER4ListI4ItemE+0x5b)[0x69f9bb]
> /mnt/mysql/bin/mysqld(_ZN19Materialized_cursor5fetchEm+0x4d)[0x6e840d]
>
> /mnt/mysql/bin/mysqld(_ZN9sp_cursor5fetchEP3THDP4ListI11sp_variableE+0xcf)[0x69f6bf]
> /mnt/mysql/bin/mysqld(_ZN7sp_head7executeEP3THDb+0x702)[0x69b1a2]
>
> /mnt/mysql/bin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x6d7)[0x69c5a7]
> /mnt/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x13f8)[0x7158d8]
>
> /mnt/mysql/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x608)[0x719a28]
>
> /mnt/mysql/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x146f)[0x71aeff]
> /mnt/mysql/bin/mysqld(_Z24do_handle_one_connectionP3T...

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Percona Server 5.6 because there has been no activity for 60 days.]

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/PS-3100

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.