Skip to content
  • Benny Wang's avatar
    aa5ca8f1
    Fixed bug#22444212: GCOLS: READ OF FREED MEMORY IN CALC_ROW_DIFFERENCE · aa5ca8f1
    Benny Wang authored
    During UPDATE, there are two places where update_generated_write_fields() will
    be called. The first place is in function fill_record. The other one is
    set_function_defaults.
    
    For updating virtual BLOB generated column, we have to avoid the BLOB content
    rewritten (Ref comments on keep_old_value()). Therefore, we use
    keep_old_value() to record the old 'value' before update. In the first call of
    update_generated_write_fields(), we keep the old 'value'. However, in the
    second call, we free the old 'value' according to the current logic.  So after
    the second calling, the old 'value' isn't kept actually. This is why such
    a bug occurs.
    
    The solution in this patch introduces a variable in Field_blob which marks
    whether the old 'value' is kept. If the variable is TRUE, we will keep the old
    'value'.  Otherwise, we will skip to keep the old 'value'. By this way, we can
    avoid the rewritten even there are two times of calling on keep_old_value().
    This variable will be set to true by update_generated_read_fields() when
    reading the record containing a virtual generated BLOB field. It will be set
    back to false when update_generated_write_fields() calls
    Field_blob::keep_old_value().
    aa5ca8f1
    Fixed bug#22444212: GCOLS: READ OF FREED MEMORY IN CALC_ROW_DIFFERENCE
    Benny Wang authored
    During UPDATE, there are two places where update_generated_write_fields() will
    be called. The first place is in function fill_record. The other one is
    set_function_defaults.
    
    For updating virtual BLOB generated column, we have to avoid the BLOB content
    rewritten (Ref comments on keep_old_value()). Therefore, we use
    keep_old_value() to record the old 'value' before update. In the first call of
    update_generated_write_fields(), we keep the old 'value'. However, in the
    second call, we free the old 'value' according to the current logic.  So after
    the second calling, the old 'value' isn't kept actually. This is why such
    a bug occurs.
    
    The solution in this patch introduces a variable in Field_blob which marks
    whether the old 'value' is kept. If the variable is TRUE, we will keep the old
    'value'.  Otherwise, we will skip to keep the old 'value'. By this way, we can
    avoid the rewritten even there are two times of calling on keep_old_value().
    This variable will be set to true by update_generated_read_fields() when
    reading the record containing a virtual generated BLOB field. It will be set
    back to false when update_generated_write_fields() calls
    Field_blob::keep_old_value().
Loading