On 7/7/10 7:40 AM, Sergey Glukhov wrote:
> #At file:///home/gluh/MySQL/mysql-5.1-bugteam/ based on
> 3467 Sergey Glukhov 2010-07-07
> Bug#54494 crash with explain extended and prepared statements
> In case of outer join and emtpy WHERE conditon
> 'always true' condition is created for WHERE clasue.
> Later in mysql_select() original SELECT_LEX WHERE
> condition is overwritten with created cond.
> However SELECT_LEX condition is also used as inital
> condition in mysql_select()->JOIN::prepare().
> On second execution of PS modified SELECT_LEX condition
> is taken and it leads to crash.
> The fix is to restore original SELECT_LEX condition
> (set to NULL if original cond is NULL) in
> HAVING clause is fixed too for safety reason
> (no test case as I did not manage to think out
> appropriate example).
I see, same problem indeed.
But I disagree with the fix approach, this is essentially a EXPLAIN
idiosyncrasy. Basically, we have code in mysql_explain_union that hooks
and extends the the lifetime of those structures, hence it should be
responsible for a proper cleanup too.
2529├> if (thd->lex->describe & DESCRIBE_EXTENDED)
2531│ select_lex->where= join->conds_history;
2532│ select_lex->having= join->having_history;
needs to be undone later down the road, it's not good practice to leave
them hanging around regardless of the execution context.
Also, something totally unrelated that I saw in mysql_select:
DBUG_RETURN(err || thd->is_error());
if free_join kicks in and it goes into cleanup, delete is called on the
join, but we later dereference the join again to get the error. This
could wreak havoc someday...