Bug #8116 calling simple stored procedure twice in a row results in server crash

Description:

I created a simple stored procedure, and upon calling it twice from the command line client the server crashes, producing the stack trace below:

#resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack 
0x808edf3 handle_segfault + 423
0x8301538 pthread_sighandler + 184
0x830cc11 kill + 17
0x83018c9 raise + 25
0x830d030 abort + 192
0x8371d38 __default_terminate + 24
0x8371d5d __terminate + 29
0x837173b __pure_virtual + 43
0x804f901 save_in_field__4ItemP5Fieldb + 289
0x805d861 convert_constant_item__FP3THDP5FieldPP4Item + 61
0x805da5b fix_length_and_dec__15Item_bool_func2 + 343
0x8056b52 fix_fields__9Item_funcP3THDP13st_table_listPP4Item + 302
0x80c069c setup_conds__FP3THDP13st_table_listT1PP4Item + 172
0x80c5843 prepare__4JOINPPP4ItemP13st_table_listUiP4ItemUiP8st_orderT6T4T6P13st_select_lexP18st_select_lex_unit + 455
0x80c8d93 mysql_select__FP3THDPPP4ItemP13st_table_listUiRt4List1Z4ItemP4ItemUiP8st_orderT7T5T7UlP13select_resultP18st_select_lex_unitP13s + 723
0x80c5623 handle_select__FP3THDP6st_lexP13select_result + 179
0x809edfa mysql_execute_command__FP3THD + 1190
0x8157550 exec_stmt__13sp_instr_stmtP3THDP6st_lex + 120
0x8157457 execute__13sp_instr_stmtP3THDPUi + 107
0x81556d4 execute__7sp_headP3THD + 220
0x8155d6f execute_procedure__7sp_headP3THDPt4List1Z4Item + 811
0x80a2753 mysql_execute_command__FP3THD + 15871
0x80a3eb9 mysql_parse__FP3THDPcUi + 265
0x809d798 dispatch_command__F19enum_server_commandP3THDPcUi + 1608
0x809d143 do_command__FP3THD + 223
0x809c85a handle_one_connection + 730
0x82fecec pthread_start_thread + 220
0x83287ca thread_start + 4

How to repeat:
CREATE PROCEDURE sp_getuserstats(
							IN _userid INT, 
							IN _timeoutseconds INT
							)
BEGIN
	
     SELECT * from users where userid = _userid;

END

CREATE TABLE `users` (
  `userid` bigint(20) NOT NULL default '0',
  `parentid` bigint(20) default '0',
  `createdate` datetime NOT NULL default '0000-00-00 00:00:00',
  `modifydate` datetime NOT NULL default '0000-00-00 00:00:00',
  `firstname` varchar(200) NOT NULL default '',
  `middlename` varchar(200) default NULL,
  `lastname` varchar(200) NOT NULL default '',
  `nickname` varchar(200) NOT NULL default '',
  `email` varchar(200) NOT NULL default '',
  `aboutme` varchar(200) NOT NULL default '',
  `password` varchar(200) NOT NULL default '',
  `primeseed` bigint(20) NOT NULL default '0',
  `statement` text NOT NULL,
  `focusprojectid` int(11) default NULL,
  `street` varchar(200) NOT NULL default '',
  `city` varchar(200) NOT NULL default '',
  `state` varchar(20) NOT NULL default '',
  `postal` varchar(20) NOT NULL default '',
  `country` varchar(200) NOT NULL default ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1 
	

Then from the mysql command line client simply call the procedure twice in a row with some integer arguments.... it will fail on the second try... 

Suggested fix:
not sure what to do to fix this... I have not been able to think of a workaround.

I modified the sp so that the query included an actual integer in the where clause instead of using the sp argument, and the error remains.

Turns out that changing the userid column to int(11) instead of bigint(20) makes the crashing stop.  Before realizing this I tried the table as InnoDB and MyISAM and the error happened in both.

Verified with 5.0.3-alpha-debug-log

Ive got the same problem with the bigint field in a simple procedure.

Trace:
0x8140e33 handle_segfault + 423
0x4004e12b _end + 933031427
0x81089bc fix_fields__9Item_funcP3THDP13st_table_listPP4Item + 120
0x8172cfc setup_conds__FP3THDP13st_table_listT1PP4Item + 172
0x8177ec3 prepare__4JOINPPP4ItemP13st_table_listUiP4ItemUiP8st_orderT6T4T6P13st_select_lexP18st_select_lex_unit + 455
0x817b503 mysql_select__FP3THDPPP4ItemP13st_table_listUiRt4List1Z4ItemP4ItemUiP8st_orderT7T5T7UlP13select_resultP18st_select_lex_unitP13s + 723
0x8177ca3 handle_select__FP3THDP6st_lexP13select_result + 179
0x815129a mysql_execute_command__FP3THD + 1206
0x82174c0 exec_stmt__13sp_instr_stmtP3THDP6st_lex + 120
0x82173c7 execute__13sp_instr_stmtP3THDPUi + 107
0x8215644 execute__7sp_headP3THD + 220
0x8215cdf execute_procedure__7sp_headP3THDPt4List1Z4Item + 811
0x8154cc6 mysql_execute_command__FP3THD + 16098
0x8156471 mysql_parse__FP3THDPcUi + 261
0x814fc28 dispatch_command__F19enum_server_commandP3THDPcUi + 1608
0x814f5d3 do_command__FP3THD + 223
0x814ecea handle_one_connection + 730
0x4004b1b0 _end + 933019272
0x4018fe4a _end + 934349602

Version: 5.0.2

Same workarround: dont use bigint! :)