List:Commits« Previous MessageNext Message »
From:Davi Arnaut Date:July 9 2010 3:19am
Subject:Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)
Bug#54494
View as plain text  
Hi Sergey,

On 7/7/10 7:40 AM, Sergey Glukhov wrote:
> #At file:///home/gluh/MySQL/mysql-5.1-bugteam/ based on
> revid:sergey.glukhov@stripped
>
>   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
>        reinit_stmt_before_use().
>        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.

The below:

  2529├>  if (thd->lex->describe & DESCRIBE_EXTENDED)
  2530│   {
  2531│     select_lex->where= join->conds_history;
  2532│     select_lex->having= join->having_history;
  2533│   }

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:

   if (free_join)
   {
     thd_proc_info(thd, "end");
     err|= select_lex->cleanup();
     DBUG_RETURN(err || thd->is_error());
   }
   DBUG_RETURN(join->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...

Regards,

Davi
Thread
bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Sergey Glukhov7 Jul
  • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Davi Arnaut9 Jul
    • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Sergey Glukhov19 Aug
      • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Davi Arnaut6 Sep
        • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Sergey Glukhov17 Sep
  • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Konstantin Osipov22 Sep
    • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Davi Arnaut23 Sep
      • Re: bzr commit into mysql-5.1-bugteam branch (Sergey.Glukhov:3467)Bug#54494Konstantin Osipov24 Sep