← Back to team overview

maria-developers team mailing list archive

Re: 39e20ca7e28: MDEV-29748 ASAN errors or server crash in File_parser::parse upon concurrent view operations

 

Hi, Sergei!

On Thu, Oct 20, 2022 at 6:23 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:

> Hi, Oleksandr,
>
> On Oct 19, Oleksandr Byelkin wrote:
> > On Wed, Oct 19, 2022 at 5:09 PM Sergei Golubchik <serg@xxxxxxxxxxx>
> wrote:
> > > On Oct 19, Oleksandr Byelkin wrote:
> > > >
> > > >    if (share->view_def->parse((uchar *) &share->tabledef_version,
> NULL,
> > > >                               view_timestamp_parameters, 1,
> > > >                               &file_parser_dummy_hook))
> > > > +  {
> > > > +    // safety if the definition file is brocken
> > > > +    share->tabledef_version.length= 0;
> > >
> > > when can view_def->parse() fail? _Only_ if the definition is invalid?
> > > Can it succeed for one TABLE and fail for another, both of the same
> > > TABLE_SHARE?
> >
> > Also if there is no memory.
> >
> > If for the other table there will be more memory or file has changed
> > it can succeed.
>
> My point is that if it is possible that two different threads would get
> different results from share->view_def->parse(), then you cannot update
> the shared share->tabledef_version.length without a lock. And you cannot
> read it without a lock.
>
> So if it is possible that two different threads would get different
> results from share->view_def->parse(), then it's best not to update
> share->tabledef_version.length here and only do it in open_table_def().
>

if we got an error as I understood it will nead to an error of opening the
table, so the query will  fail.

The other thread may have memory but it is true for any EOM situation and
there are a lot of places where we allocate memory, so I do not see how
this will differ.

The same with changing frm file with a working server, I do not think that
our server will survive if something out of the server will change frms.


> Regards,
> Sergei
> VP of MariaDB Server Engineering
> and security@xxxxxxxxxxx
>

Follow ups

References