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: | |
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
[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