• Chaithra Gopalareddy's avatar
    Bug#19941403: FATAL_SIGNAL(SIG 6) IN BUILD_EQUAL_ITEMS_FOR_COND | IN SQL/SQL_OPTIMIZER.CC:1657 · a7fb5aec
    Chaithra Gopalareddy authored
    Problem:
    At the end of first execution select_lex->prep_where is pointing to
    a runtime created object (temporary table field). As a result
    server exits trying to access a invalid pointer during second
    execution.
    
    Analysis:
    While optimizing the join conditions for the query, after the
    permanent transformation, optimizer makes a copy of the new
    where conditions in select_lex->prep_where. "prep_where" is what
    is used as the "where condition" for the query at the start of execution.
    W.r.t the query in question, "where" condition is actually pointing
    to a field in the temporary table. As a result, for the  second
    execution the pointer is no more valid resulting in server exit.
    
    Fix:
    At the end of the first execution, select_lex->where will have the
    original item of the where condition.
    Make prep_where the new place where the original item of select->where
    has to be rolled back.
    Fixed in 5.7 with the wl#7082 - Move permanent transformations from
    JOIN::optimize to JOIN::prepare
    
    Patch for 5.5 includes the following backports from 5.6:
    
    Bugfix for Bug12603141 - This makes the first execute statement in the testcase
    pass in 5.5
    
    However it was noted later in in Bug16163596 that the above bugfix needed to
    be modified. Although Bug16163596 is reproducible only with changes done for
    Bug12582849, we have decided include the fix.
    
    Considering that Bug12582849 is related to Bug12603141, the fix is
    also included here. However this results in Bug16317817, Bug16317685,
    Bug16739050. So fix for the above three bugs is also part of this patch.
    a7fb5aec
sql_select.cc 580 KB