Crash when selecting from GLOBAL_TEMPORARY_TABLES with parallel online ALTER TABLE

About 6-7 ALTER TABLES were running for several hours.

I can able to reproduce this with 5.6.16-64.

mysql> select count(*) from test1;
+----------+
| count(*) |
+----------+
| 50331648 |
+----------+
1 row in set (17.05 sec)

mysql> ALTER TABLE test1 ADD COLUMN email varchar(30);
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>

After running alter table, when I have checked from another session

mysql> SELECT * FROM GLOBAL_TEMPORARY_TABLES;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>

In error log,

10:09:34 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=131072
max_used_connections=2
max_threads=153
thread_count=2
connection_count=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 77348 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7fed0c4da860
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 = 7fecd892ae10 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x7fed096ad63c]
/usr/sbin/mysqld(handle_fatal_signal+0x3cb)[0x7fed093fd5fb]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x7fed078cdbb0]
/usr/sbin/mysqld(_ZN7handler5cloneEPKcP11st_mem_root+0x1c)[0x7fed0932decc]
/usr/sbin/mysqld(+0x7c00b1)[0x7fed097640b1]
/usr/sbin/mysqld(+0x51f94d)[0x7fed094c394d]
/usr/sbin/mysqld(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x2d0)[0x7fed094d2b50]
/usr/sbin/mysqld(_ZN4JOIN14prepare_resultEPP4ListI4ItemE+0xa5)[0x7fed094b2185]
/usr/sbin/mysqld(_ZN4JOIN4execEv+0xac)[0x7fed094661dc]
/usr/sbin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_P10SQL_I_ListI8st_orderESB_S7_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x23d)[0x7fed094b278d]
/usr/sbin/mysqld(_Z13handle_selectP3THDP13select_resultm+0x165)[0x7fed094b3075]
/usr/sbin/mysqld(+0x34a75a)[0x7fed092ee75a]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x2086)[0x7fed0948e606]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x608)[0x7fed09493788]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x237b)[0x7fed0949618b]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x22d)[0x7fed0945aa9d]
/usr/sbin/mysqld(handle_one_connection+0x40)[0x7fed0945ab20]
/usr/sbin/mysqld(pfs_spawn_thread+0x140)[0x7fed096fb730]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x7fed078c5f6e]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fed06fe89cd]

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

Couldn't able to reproduced this with 5.1 and 5.5. It might be solved with this.
https://bugs.launchpad.net/percona-server/+bug/745241

5.1 and 5.5 are probably affected, but the current bug status is fine for now.

this is still happening. try doing an alter table with in place algo

running Server version: 5.6.16-64.2-569.precise-log (Ubuntu)

I tested with Percona Server 5.1.73 and 5.5.37 and do not see any crash.

I tested with Percona Server 5.6.17 and I did see the crash.

Using ALGORITHM=COPY for the alter table avoids the crash. Only with default or ALGORITHM=INPLACE does it crash.

My test to reproduce the crash:

use test;
drop table if exists foo;
create table foo (id serial primary key);
insert into foo select null;
insert into foo select null from foo;
...repeat insert, doubling rows each time, until the table is large enough to make alter take a few seconds at least...

alter table foo add column x int, add key (x), algorithm=inplace;
...this should take a few seconds, giving you time to switch to another window and run...

select * from information_schema.global_temporary_tables;

Is this fixed in 5.6.19? According to Oracle's change log (http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-19.html):

"Certain INFORMATION_SCHEMA queries could cause a server exit"

No, it's not fixed. The issue is unrelated to the one Oracle fixed in 5.6.19.

We just experienced this crash on our primary production systems, causing site downtime. It was surprising and frustrating that a simple SELECT could crash the server.

Is there anyone assigned to fixing this bug?

Thanks

And here is the backtrace from the error log
-----------------------

23:49:46 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=8388608
read_buffer_size=131072
max_used_connections=3001
max_threads=3002
thread_count=2115
connection_count=2115
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1232732 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x26a279560
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...
/mysql/bin/mysqld'my_print_stacktrace+0x1e [0x9e296b]
/mysql/bin/mysqld'handle_fatal_signal+0x22c [0x841d54]
/lib/amd64/libc.so.1'__sighndlr+0x6 [0xfffffd7fff29fbc6]
/lib/amd64/libc.so.1'call_user_handler+0x1db [0xfffffd7fff292a1b]
/mysql/bin/mysqld'_ZN7handler5cloneEPKcP11st_mem_root+0x1f [0x7dc027] [Signal 11 (SEGV)]
/mysql/bin/mysqld'_ZN11ha_innobase5cloneEPKcP11st_mem_root+0xe [0xa562a0]
/mysql/bin/mysqld'_ZL28store_temporary_table_recordP3THDP5TABLES2_PKc+0xf7 [0x8b7b54]
/mysql/bin/mysqld'_ZL28fill_global_temporary_tablesP3THDP10TABLE_LISTP4Item+0x162 [0x8b7e7e]
/mysql/bin/mysqld'_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x21d [0x8bbfac]
/mysql/bin/mysqld'_ZN4JOIN14prepare_resultEPP4ListI4ItemE+0x66 [0x8a9c8c]
/mysql/bin/mysqld'_ZN4JOIN4execEv+0x122 [0x87fcfa]
/mysql/bin/mysqld'_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_P10SQL_I_ListI8st_orderESB_S7_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x270 [0x8aff5a]
/mysql/bin/mysqld'_Z13handle_selectP3THDP13select_resultm+0x153 [0x8b0167]
/mysql/bin/mysqld'_ZL21execute_sqlcom_selectP3THDP10TABLE_LIST+0x1a4 [0xb9eab8]
/mysql/bin/mysqld'_Z21mysql_execute_commandP3THD+0x605 [0x892cda]
/mysql/bin/mysqld'_Z11mysql_parseP3THDPcjP12Parser_state+0x518 [0x89735b]
/mysql/bin/mysqld'_Z16dispatch_command19enum_server_commandP3THDPcj+0x7be [0x897b7d]
/mysql/bin/mysqld'_Z24do_handle_one_connectionP3THD+0x122 [0x876afd]
/mysql/bin/mysqld'handle_one_connection+0x39 [0x876bba]
/mysql/bin/mysqld'pfs_spawn_thread+0xbd [0xa3d7dc]
/lib/amd64/libc.so.1'_thrp_setup+0x8a [0xfffffd7fff29f7ea]
/lib/amd64/libc.so.1'_lwp_start+0x0 [0xfffffd7fff29fb00]
Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.html
and follow instructions on how to resolve the stack trace.
Resolved stack trace is much more helpful in diagnosing the
problem, so please do resolve it

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (26a6afda0): select * from information_schema.GLOBAL_TEMPORARY_TABLES
Connection ID (thread ID): 3386800596
Stat...

Is this a Percona problem only or does this problem also exist in other 5.6 distros, such as the Community edition, MariaDB, etc.?

The problem is specific to Percona Server to the best of my knowledge. Fixing this bug is in our plans.

Also see bug 1367922

Still reproducible for Percona Server 5.6.21 - select from information_schema.global_temporary_tables during an alter is in progress crashes the server:

mysql [localhost] {msandbox} (test) > show processlist; select * from information_schema.global_temporary_tables;
+----+----------+-----------+------+---------+------+----------------+------------------------------------------------------------------+-----------+---------------+
| Id | User | Host | db | Command | Time | State | Info | Rows_sent | Rows_examined |
+----+----------+-----------+------+---------+------+----------------+------------------------------------------------------------------+-----------+---------------+
| 1 | msandbox | localhost | test | Query | 0 | altering table | alter table foo add column x int, add key (x), algorithm=inplace | 0 | 0 |
| 2 | msandbox | localhost | test | Query | 0 | init | show processlist | 0 | 0 |
+----+----------+-----------+------+---------+------+----------------+------------------------------------------------------------------+-----------+---------------+
2 rows in set (0.00 sec)

ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql [localhost] {msandbox} (test) > select * from information_schema.global_temporary_tables;
ERROR 2006 (HY000): MySQL server has gone away

I tested also select from other tables, like 'TEMPORARY_TABLES', 'TABLES', 'TABLESPACES', 'ENGINES', etc. but no crash happens, only GLOBAL_TEMPORARY_TABLES seems affected.

THis is marked as fixed. In which version is it fixed?

Fixed in 5.6.22: https://www.percona.com/doc/percona-server/5.6/release-notes/Percona-Server-5.6.22-71.0.html ("Selecting from GLOBAL_TEMPORARY_TABLES table while running an online ALTER TABLE in parallel could lead to server crash.")

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