I think I managed to fix the issue. I uploaded the code it is a little
sloppy yet but it is late where I am at and required a large rewrite
of some sections. I will go over it more tomorrow as it is 12:30 am
now. I will also check the rest of my tests against the new code
tomorrow as well. I am looking into the type ulonglong and seeing
what SHOW type it returns unless it is simply longlong which is
On Aug 15, 2009, at 6:28 PM, Joseph Lukas wrote:
> I am having last minute issues with these 2 statements. I have
> spent most of the day looking at the issue but have not had any luck
> solving it. If the prepared statements contain a SET STATEMENT they
> will work fine.
> However when you put something like SET STATEMENT var1 = X FOR
> EXECUTE mystatement1; I get errors/crash. After working on it for
> most of the day I have determined that the error is caused by the
> Items being removed. The pointers become invalid and forces a
> crash. The set_var, and sys_var's both stay valid from my set_var
> list used by the reset function only the Items containing the values
> It works up until the reset function is called. The function goes to
> var->check and crashes. The code you have is fine to get the same
> error. if you comment out DBUG_ASSERT(thd->free_list == NULL); in
> sql_prepare line 3387. I bypassed it with an if(!thd->lex-
> >stmt_set_list.is_empty()). In code on launchpad.
> I have been looking at ways around this but all Items in order for
> clean up seem to be pushed into the thd->free_list.
> I have yet to figure out why or exactly where they are all deleted
> or dropped as I even moved them out of the thd->lex and into a
> structure in sql_parse.
> This is the only issue I have I am less worried on having SET
> STATEMENT ... FOR PREPARE but I am sure SET STATEMENT ... FOR
> EXECUTE could be possible and should be. I cannot figure out why/
> where the Items are being deleted.
> If I remove the reset function the remainder works as it should and
> sets the variables and builds the structures to reset. I even re-
> did the function as to reset the variables after setting them to
> make sure it was caused after the SQLCOM_EXECUTE functions.
> I am finishing some of the code cleanup and at least writing the
> tests. The only ones I have left to test for are the ones dealing
> with EXECUTE.
> Like I said the PREPARE statements seem to work fine when the SET
> STATEMENT is in the prepared statement like
> PREPARE stmt1 FROM 'SET STATEMENT sort_buffer=1000000 FOR SELECT *
> FROM test';
> I pushed most current code as well to launchpad. I have to finish
> SHOW_DOUBLE a few comments and have about 5 more tests to write then
> I can come back to this. I have been about 10 hours at this trying
> various methods but have other sections to finish.