← Back to team overview

maria-developers team mailing list archive

Re: 67260fd: MDEV-15130 Assertion `table->s->null_bytes == 0' failed in ...

 

Hi, Sachin!

On Apr 19, sachin wrote:

> diff --git a/storage/perfschema/ha_perfschema.cc b/storage/perfschema/ha_perfschema.cc
> index e8e9581..d5846f2 100644
> --- a/storage/perfschema/ha_perfschema.cc
> +++ b/storage/perfschema/ha_perfschema.cc
> @@ -64,6 +64,16 @@ static int pfs_discover_table(handlerton *hton, THD *thd, TABLE_SHARE *share)
>  {
>    const PFS_engine_table_share *pfs_share;
>  
> +  DBUG_EXECUTE_IF("test_pseudo_invisible", {
> +         my_error(ER_INTERNAL_ERROR, MYF(0), "Don't query performance_schema when"
> +                 "test_pseudo_invisible is on");
> +         return 1;
> +         });
> +  DBUG_EXECUTE_IF("test_completely_invisible", {
> +         my_error(ER_INTERNAL_ERROR, MYF(0), "Don't query performance_schema when"
> +                 "test_completely_invisible is on");
> +         return 1;
> +         });
>    if ((pfs_share= find_table_share(share->db.str, share->table_name.str)))
>      return share->init_from_sql_statement_string(thd, false,
>                                                   pfs_share->sql.str,

Better put it inside TABLE_SHARE::init_from_sql_statement_string to
cover Connect and FederatedX too.

Or - I'd say it's an option too - just close it as not a bug.
DBUG_EXECUTE_IF can cause a crash, can make a server to misbehave, etc.
That's normal, it's a debug hack that intentionally makes server to do
something weird. I wouldn't spend too much time on making it user
friendly and error-proof.

Regards,
Sergei
Chief Architect MariaDB
and security@xxxxxxxxxxx


Follow ups