• Evgeny Potemkin's avatar
    Bug#48508: Crash on prepared statement re-execution. · 7853f553
    Evgeny Potemkin authored
    Actually there is two different bugs.
    The first one caused crash on queries with WHERE condition over views
    containing WHERE condition. A wrong check for prepared statement phase led
    to items for view fields being allocated in the execution memory and freed
    at the end of execution. Thus the optimized WHERE condition refers to
    unallocated memory on the second execution and server crashed.
    The second one caused by the Item_cond::compile function not saving changes
    it made to the item tree. Thus on the next execution changes weren't
    reverted and server crashed on dereferencing of unallocated space.
    
    The new helper function called is_stmt_prepare_or_first_stmt_execute
    is added to the Query_arena class.
    The find_field_in_view function now uses
    is_stmt_prepare_or_first_stmt_execute() to check whether
    newly created view items should be freed at the end of the query execution.
    The Item_cond::compile function now saves changes it makes to item tree.
    
    mysql-test/r/ps.result:
      Added a test case for the bug#48508.
    mysql-test/t/ps.test:
      Added a test case for the bug#48508.
    sql/item_cmpfunc.cc:
      Bug#48508: Crash on prepared statement re-execution.
      The Item_cond::compile function now saves changes it makes to item tree.
    sql/sql_base.cc:
      Bug#48508: Crash on prepared statement re-execution.
      The find_field_in_view function now uses
      is_stmt_prepare_or_first_stmt_execute() to check whether
      newly created view items should be freed at the end of the query execution.
    sql/sql_class.h:
      Bug#48508: Crash on prepared statement re-execution.
      The Query_arena::is_stmt_prepare_or_first_sp_execute function now correctly
      do its check.
    7853f553
sql_base.cc 198 KB