• Gopal Shankar's avatar
    Bug#13105873 :Valgrind Warning: CRASH IN FOREIGN · 5fe4986c
    Gopal Shankar authored
          KEY HANDLING ON SUBSEQUENT CREATE TABLE IF NOT EXISTS
          
          PROBLEM:
          --------
          Consider a SP routine which does CREATE TABLE
          with REFERENCES clause. The first call to this routine
          invokes parser and the parsed items are cached, so as 
          to avoid parsing for the second execution of the routine.
          
          It is obsevered that valgrind reports a warning
          upon read of thd->lex->alter_info->key_list->Foreign_key object,
          which seem to be pointing to a invalid memory address
          during second time execution of the routine. Accessing this object
          theoretically could cause a crash.
          
          ANALYSIS:
          ---------
          The problem stems from the fact that for some reason
          elements of ref_columns list in thd->lex->alter_info->
          key_list->Foreign_key object are changed to point to
          objects allocated on runtime memory root.
          
          During the first execution of routine we create
          a copy of thd->lex->alter_info object.
          As part of this process we create a clones of objects in
          Alter_info::key_list and of Foreign_key object in particular.
          Then Foreign_key object is cloned for some reason we
          perform shallow copies of both Foreign_key::ref_columns
          and Foreign_key::columns list. So new instance of 
          Foreign_key object starts to SHARE contents of ref_columns
          and columns list with the original instance.
          After that as part of cloning process we call
          list_copy_and_replace_each_value() for elements of
          ref_columns list. As result ref_columns lists in both
          original and cloned Foreign_key object start to contain
          pointers to Key_part_spec objects allocated on runtime
          memory root because of shallow copy.
          
          So when we start copying of thd->lex->alter_info object
          during the second execution of stored routine we indeed
          encounter pointer to the Key_part_spec object allocated
          on runtime mem-root which was cleared during at the end
          of previous execution. This is done in sp_head::execute(), 
          by a call to free_root(&execute_mem_root,MYF(0));
          As result we get valgrind warnings about accessing 
          unreferenced memory.
          
          FIX:
          ----
          The safest solution to this problem is to 
          fix Foreign_key(Foreign_key, MEM_ROOT) constructor to do
          a deep copy of columns lists, similar to Key(Key, MEM_ROOT) 
          constructor.
    5fe4986c
sp-bugs.result 3.04 KB