Bug #23782 Stored procedures: crash if variable in procedure analyse
Submitted: 30 Oct 2006 18:17 Modified: 20 Feb 2007 20:08
Reporter: Peter Gulutzan Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Stored Routines Severity:S3 (Non-critical)
Version:5.0, 5.1.13-beta-debug OS:Linux (SUSE 10.0 / 64-bit)
Assigned to: Ramil Kalimullin CPU Architecture:Any

[30 Oct 2006 18:17] Peter Gulutzan
Description:
I create a procedure which has a declared variable, and a SELECT statement
that includes a PROCEDURE ANALYSE which uses the declared variable.
I call it.
Crash.

How to repeat:
mysql> create procedure p3 () begin declare v int default 10; select 5 from information_schema.tables procedure analyse (v,2000); end//
Query OK, 0 rows affected (0.00 sec)

mysql> call p3()//
ERROR 2013 (HY000): Lost connection to MySQL server during query
[30 Oct 2006 18:39] Miguel Solorzano
Thank you for the bug report. Verified on Suse 32-bit as described.

mysql> delimiter //
mysql> create procedure p3 () begin declare v int default 10; select 5 from
    -> information_schema.tables procedure analyse (v,2000); end//
Query OK, 0 rows affected (0.02 sec)

mysql>  call p3()//
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
[24 Nov 2006 12:39] Andrey Hristov
Crashes 5.0 too
Actually an assert
Version: '5.0.30-valgrind-max-debug-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
mysqld: item.cc:890: virtual double Item_sp_variable::val_real(): Assertion `fixed' failed.
mysqld got signal 6;
[24 Nov 2006 12:42] Andrey Hristov
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x400fb2c1 in raise () from /lib/tls/libc.so.6
#2  0x400fcb75 in abort () from /lib/tls/libc.so.6
#3  0x400f4903 in __assert_fail () from /lib/tls/libc.so.6
#4  0x0812bd62 in Item_sp_variable::val_real (this=0x8c56a70) at item.cc:890
#5  0x082d09db in proc_analyse_init (thd=0x8c610b0, param=0x8c56b80, result=0x0, field_list=@0x8c62914)
    at sql_analyse.cc:90
#6  0x08238a03 in setup_procedure (thd=0x0, param=0x8c56a10, result=0x0, field_list=@0x0, error=0x8c782c0)
    at procedure.cc:91
#7  0x08201c5c in JOIN::prepare (this=0x8c774f0, rref_pointer_array=0x8c629d0, tables_init=0x0, wild_num=0,
    conds_init=0x0, og_num=0, order_init=0x0, group_init=0x0, having_init=0x0, proc_param_init=0x0,
    select_lex_arg=0x8c62884, unit_arg=0x8c6264c) at sql_select.cc:454
#8  0x08205d13 in mysql_select (thd=0x8c610b0, rref_pointer_array=0x8c629d0, tables=0x8c56780, wild_num=0, fields=@0x0,
    conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x8c56a10, select_options=2693024256,
    result=0x8c774c8, unit=0x8c6264c, select_lex=0x8c62884) at sql_select.cc:1995
#9  0x0820138f in handle_select (thd=0x8c610b0, lex=0x8c625e8, result=0x8c774c8, setup_tables_done_option=0)
    at sql_select.cc:245
#10 0x081c8493 in mysql_execute_command (thd=0x8c610b0) at sql_parse.cc:2596
#11 0x08311d21 in sp_instr_stmt::exec_core (this=0x6, thd=0x0, nextp=0x6) at sp_head.cc:2492
#12 0x083119ee in sp_lex_keeper::reset_lex_and_exec_core (this=0x8c5f594, thd=0x8c610b0, nextp=0x0, open_tables=false,
    instr=0x8c5f568) at sp_head.cc:2368
#13 0x08311bcd in sp_instr_stmt::execute (this=0x8c5f568, thd=0x8c610b0, nextp=0x4200364c) at sp_head.cc:2445
#14 0x0830e56b in sp_head::execute (this=0x8c67d90, thd=0x8c610b0) at sp_head.cc:1057
#15 0x0830fb80 in sp_head::execute_procedure (this=0x8c67d90, thd=0x8c610b0, args=0x8c6163c) at sp_head.cc:1687
#16 0x081cd7d6 in mysql_execute_command (thd=0x8c610b0) at sql_parse.cc:4476
#17 0x081d0873 in mysql_parse (thd=0x8c610b0, inBuf=0x8c60ba8 "call p3()", length=9) at sql_parse.cc:5807
#18 0x081c67aa in dispatch_command (command=COM_QUERY, thd=0x8c610b0, packet=0x8c5fac9 "call p3()", packet_length=10)
    at sql_parse.cc:1773
#19 0x081c608b in do_command (thd=0x8c610b0) at sql_parse.cc:1557
#20 0x081c521d in handle_one_connection (arg=0x0) at sql_parse.cc:1188
#21 0x4005caa7 in start_thread () from /lib/tls/libpthread.so.0
#22 0x4018dc2e in clone () from /lib/tls/libc.so.6
[6 Dec 2006 12:12] Bugs System
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/16511

ChangeSet@1.2338, 2006-12-06 16:13:34+04:00, ramil@mysql.com +1 -0
  Fix for bug #23782: Stored procedures: crash if variable in procedure analyse
  
  We have to call fix_fields() for procedure analyse' arguments as they may not be
  fixed in some circumstances.
  Test case will be added later (when we have binlog_disabled.test).
[6 Feb 2007 11:58] Bugs System
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/19378

ChangeSet@1.2358, 2007-02-06 15:58:40+04:00, ramil@mysql.com +1 -0
  Fix for bug #23782: Stored procedures: crash if variable in procedure
  analyse
  
  We have to call fix_fields() for procedure analyse' arguments as they may   
  not be
  fixed in some circumstances.
  
  (as the crash appears when mysqld starts skipping binlog, a test case
  will be added when we can --skip-bin-log in -master.opt)
[14 Feb 2007 15:07] Chad MILLER
Available in 5.0.36 and 5.1.16-beta.
[20 Feb 2007 20:08] Paul Dubois
Noted in 5.0.36, 5.1.16 changelogs.

Within a stored routine, accessing a declared routine variable with
PROCEDURE ANALYSE() caused a server crash.