Bug #15840 Empty named stored proc - "lost connection to mysql server...."
Submitted: 19 Dec 2005 0:34 Modified: 10 Jan 2006 13:49
Reporter: Peter Larb Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.0.18-BK, 5.0.16 OS:Linux (Linux, sun-solaris2.9 (sparc))
Assigned to: Assigned Account CPU Architecture:Any

[19 Dec 2005 0:34] Peter Larb
Description:
Good morning

refer bug #15801

I said previoously to create the stored procedure with no content but in fact you must create a proc with no name - refer "How to Repeat".

I have had to uninstall MySQL and re-install !

Please treat with more urgency.

Thankyou

Peter

Please see error screen shot.

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=268435456
read_buffer_size=1044480
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 466543 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.

051219 10:45:00  mysqld restarted
051219 10:45:00  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
051219 10:45:00  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 8694053.
InnoDB: Doing recovery: scanned up to log sequence number 0 8694053
InnoDB: Last MySQL binlog file position 0 5012527, file name ./mysql-bin.000003
051219 10:45:01  InnoDB: Started; log sequence number 0 8694053
051219 10:45:01 [Note] Recovering after a crash using mysql-bin
051219 10:45:01 [Note] Starting crash recovery...
051219 10:45:01 [Note] Crash recovery finished.
051219 10:45:01 [Warning] 'user' entry 'root@sid' ignored in --skip-name-resolve mode.
051219 10:45:01 [Warning] 'user' entry '(null)@sid' ignored in --skip-name-resolve mode.
051219 10:45:01 [Note] /export2/mysql/mysql/bin/mysqld: ready for connections.
Version: '5.0.16-max-log'  socket: '/tmp/mysql.sock'  port: 3306  MySQL Community Edition -  Experimental (GPL)

How to repeat:
mysql> create procedure ``(OUT a INT) set a:=1;
Query OK, 0 rows affected (0.01 sec)

mysql> show procedure status;
Error: Lost connection to MySQL server during query
[19 Dec 2005 9:32] Valeriy Kravchuk
Thank you for a bug report. Verified just as described on 5.0.18-BK (ChangeSet@1.1981, 2005-12-15 02:08:52-03:00) on Linux (note, that "use test" was performed before):

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.0.18    |
+-----------+
1 row in set (0.06 sec)

mysql> create procedure ``(OUT a INT) set a:=1;
Query OK, 0 rows affected (0.03 sec)

mysql> show procedure status;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
Number of processes running now: 0
051219 12:16:37  mysqld restarted

mysql> exit
Bye
[openxs@Fedora 5.0]$ tail -40 var/Fedora.err
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 Kbytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x9416c90
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=0xb8d3b4dc, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8152125
0x64ef18
0x95254e8
0x8215b9a
0x8197e26
0x819802d
0x8194572
0x816533c
0x816cda2
0x8163e6a
0x8163a25
0x8162ec2
0x64879c
0x49527a
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 0x94468a8 = show procedure status
thd->thread_id=19
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.

Number of processes running now: 0
051219 12:16:37  mysqld restarted
051219 12:16:39  InnoDB: Started; log sequence number 0 51655374
051219 12:16:39 [Note] /home/openxs/dbs/5.0/libexec/mysqld: ready for connections.
Version: '5.0.18'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution

The resolved stack trace fives the following:

[openxs@Fedora 5.0]$ nm -n libexec/mysqld > /tmp/mysqld.sym
[openxs@Fedora 5.0]$ bin/resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack
0x8152125 handle_segfault + 565
0x64ef18 (?)
0x95254e8 _end + 16681008
0x8215b9a _Z24get_schema_tables_resultP4JOIN + 258
0x8197e26 _ZN4JOIN4execEv + 5738
0x819802d _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orde
rSB_S2_SB_mP13select_resultP18st_select_lex_unitP13st_sel + 209
0x8194572 _Z13handle_selectP3THDP6st_lexP13select_resultm + 234
0x816533c _Z21mysql_execute_commandP3THD + 592
0x816cda2 _Z11mysql_parseP3THDPcj + 294
0x8163e6a _Z16dispatch_command19enum_server_commandP3THDPcj + 1034
0x8163a25 _Z10do_commandP3THD + 129
0x8162ec2 handle_one_connection + 466
0x64879c (?)
0x49527a (?)
[19 Dec 2005 21:56] Peter Larb
I just read MySQL Bugs: #15367

I thought that it was also related and it might help you at MySQL

As it also referred to a missing stored procedure.

Thankyou

Peter
[10 Jan 2006 13:49] Per-Erik Martin
This is a duplicate of BUG#15658