← Back to team overview

maria-developers team mailing list archive

Re: [Commits] 39bce67: MDEV-11196: Error:Run-Time Check Failure #2 - Stack around the variable 'key_buff'

 

Hi Varun,

First reaction:

> diff --git a/sql/sql_table.cc b/sql/sql_table.cc
> index 84e4018..63636f9 100644
> --- a/sql/sql_table.cc
> +++ b/sql/sql_table.cc
> @@ -3948,7 +3948,11 @@ mysql_prepare_create_table(THD *thd, HA_CREATE_INFO *create_info,
>        key_part_info->fieldnr= field;
>        key_part_info->offset=  (uint16) sql_field->offset;
>        key_part_info->key_type=sql_field->pack_flag;
> -      uint key_part_length= sql_field->key_length;
> +      uint key_part_length= MY_MAX(sql_field->key_length,
> +                                   sql_field->pack_length);

What does the above do? It is not clear why MAX should be used. (Let's denote
the compared variables X and Y. Can X>Y and X<Y both happen in practice? 
This requires a comment!)

> +
> +      if (!(sql_field->flags & NOT_NULL_FLAG))
> +          key_part_length++;
>  
>        if (column->length)
>        {

I am concerned that the above may have an undesired effect:
key_part_kength counts NULL-byte while previously it did not.

Let's try this example:

create table t1 (pk int not null primary key,   col1 int,   key(col1) ) engine=innodb;

Run it, and put a breakpoint below on this code:

      /* Check if the key segment is partial, set the key flag accordingly */
      if (key_part_length != sql_field->key_length)
        key_info->flags|= HA_KEY_HAS_PART_KEY_SEG;


You will see that for filed 'col1'  HA_KEY_HAS_PART_KEY_SEG flag is now set.
This didn't happen before. Is this really intended?

I wasn't able to find what exactly may get wrong, but if I run this query:

explain select * from t1 where col1=1;                                                                                                                                                               
then it hangs.
BR
 Sergei
-- 
Sergei Petrunia, Software Developer
MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog