Bug #18177 any access to INFORMATION_SCHEMA.ROUTINES crashes

Description:
Any access to INFORMATION_SCHEMA.ROUTINES causes the server thread to crash with signal 11, giving a disconnect symptom exactly like in bug #14773.

I believe that this issue is data dependant, likely on data in the mysql database.  I have a second MySQL 5.0.18 server that does not exhibit the issue.  This server was 5.0.18, upgrading to 5.0.19 had no effect.  Restarting the service has no effect, neither does running "mysql_upgrade".

In the below section is a mysql session showing the crash, the relevant chunks of the logfile, and a resolution of the stack trace mysqld produced.

How to repeat:
[root@server mysql]# mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3569 to server version: 5.0.19-standard

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> select * from information_schema.routines;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Information from mysql.err logfile:

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.

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=38
max_connections=10240
threads_connected=23
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1327024 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0xa5da788
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...
Cannot determine thread, fp=0x18c99c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x815d800
0xde6f88
0xa658ec8
0x822dcaf
0x81a2723
0x81a295e
0x819eb83
0x8172d69
0x817a230
0x8171443
0x8170f7d
0x81704c0
0xde0dd8
0xc83d1a
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.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...
thd->query at 0xa79d898 = select * from information_schema.routines
thd->thread_id=3569
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Resolved stack trace:

[root@server root]# resolve_stack_dump -s /usr/lib/mysql/mysqld.sym -n mysql.stack
0x815d800 handle_segfault + 416
0xde6f88 (?)
0xa658ec8 _end + 34496664
0x822dcaf _Z24get_schema_tables_resultP4JOIN + 271
0x81a2723 _ZN4JOIN4execEv + 5795
0x81a295e _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_mP13select_resultP18st_select_lex_unitP13st_sel + 286
0x819eb83 _Z13handle_selectP3THDP6st_lexP13select_resultm + 307
0x8172d69 _Z21mysql_execute_commandP3THD + 601
0x817a230 _Z11mysql_parseP3THDPcj + 304
0x8171443 _Z16dispatch_command19enum_server_commandP3THDPcj + 1139
0x8170f7d _Z10do_commandP3THD + 141
0x81704c0 handle_one_connection + 656
0xde0dd8 (?)
0xc83d1a (?)

Thank you for a problem report. Can you send or upload a dump of your (or, even better, the smallest one) mysql database (or ROUTINES table at least) that demonstrate the behaviour you described?

I have narrowed the issue down to a particular procedure.  The problem appears to be that a procedure was somehow created named ''.  I'll attach a dump of mysql.proc that includes just this single stored procedure.

Deleting this entry from mysql.proc corrects the crash issue and allows normal use of stored procedures.  Unfortunately, I don't have an explanation as to how this was created, especially by a user without SUPER privileges.

This dump creates a stored procedure named '', and causes the indicated crashes

Attachment: suspect.sql (text/x-sql), 3.11 KiB.

Verified with 5.0.21-BK (ChangeSet@1.2097, 2006-04-21 20:24:52+02:00) on Linux:

openxs@suse:~/dbs/5.0> bin/mysql -uroot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6 to server version: 5.0.21

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> INSERT INTO `proc` VALUES ('test','','PROCEDURE','','SQL','CONTAINS_SQL'
,'NO','DEFINER','','','BEGIN\r\n  \r\nEND','root@%','2006-03-02 18:40:03','2006
-03-02 18:40:03','','');
Query OK, 1 row affected (0.01 sec)

mysql> select * from information_schema.routines;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
Number of processes running now: 0
060422 16:28:31  mysqld restarted

So, test case (to be run as root) is simple:

INSERT INTO `mysql`.`proc` VALUES ('test', '', 'PROCEDURE', '', 'SQL', 'CONTAINS_SQL', 'NO', 'DEFINER', '', '', 'BEGIN\r\n  \r\nEND', 'root@%', '2006-03-02 18:40:03', '2006-03-02 18:40:03', '', '');
select * from information_schema.routines;

Even if this action is incorrect, but only valid SQL statements were used and it should not lead to server's crash!

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/5461

The patch looks ok to push.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/5936

Fixed in 5.0.22

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/6304

Noted in 5.0.22 changelog.

An entry in the <literal>mysql.proc</literal> table with an
empty routine name caused access to the
<literal>INFORMATION_SCHEMA.ROUTINES</literal> table to crash
the server.