Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-24491

db_name mismatch happens during virtual column computation

Details

    Description

      After sending a simple DELETE FROM emails WHERE id=13, "MySQL has gone away". Indeed, the server crashed and left us with a core dump. In its error log, it says this:

      2020-12-10 22:19:42 14 [ERROR] [FATAL] InnoDB: Unknown error Cannot allocate memory
      		 
      201210 22:19:42 [ERROR] mysqld got signal 6

      And the core dump shows this backtrace:

      #0  0x00007f3f8c4f17ff in raise () from /lib64/libc.so.6
      		 
      #1  0x00007f3f8c4dbcfe in abort () from /lib64/libc.so.6
      		 
      #2  0x00005612c60ee0d9 in ib::fatal::~fatal() [clone .cold.29] ()
      		 
      #3  0x00005612c60dd6db in row_mysql_handle_errors(dberr_t*, trx_t*, que_thr_t*, trx_savept_t*) [clone .cold.202] ()
      		 
      #4  0x00005612c665442f in row_update_for_mysql(row_prebuilt_t*) ()
      		 
      #5  0x00005612c6596c50 in ha_innobase::delete_row(unsigned char const*) ()
      		 
      #6  0x00005612c6408a1f in handler::ha_delete_row(unsigned char const*) ()
      		 
      #7  0x00005612c6534b72 in mysql_delete(THD*, TABLE_LIST*, Item*, SQL_I_List<st_order>*, unsigned long long, unsigned long long, select_result*) ()
      		 
      #8  0x00005612c61ee5a8 in mysql_execute_command(THD*) ()
      		 
      #9  0x00005612c61f4b51 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) ()
      		 
      #10 0x00005612c61f796d in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) ()
      		 
      #11 0x00005612c61f8aa6 in do_command(THD*) ()
      		 
      #12 0x00005612c62dc65e in do_handle_one_connection(CONNECT*) ()
      		 
      #13 0x00005612c62dc72d in handle_one_connection ()
      		 
      #14 0x00007f3f8e4c914a in start_thread () from /lib64/libpthread.so.0
      		 
      #15 0x00007f3f8c5b6f23 in clone () from /lib64/libc.so.6

      "Cannot allocate memory" is simply wrong. Modifying hardware parameters or database configuration files does not change anything. You can actually solve the problem by renaming the database to something that does not contain any hyphens.

      But: MariaDB should not die like this. If it does not like the database's name, operators should be restricted from using such names. If such a database name is used, error messages must not tell tales about memory allocation that lead to wasted time finding the root cause.

      I tried to reduce the content and structure of the database that exhibits this problem to a minimum case, from 32 MB to 32 kB with only three tables and anonymized content. I really hope you can find this bug, as I guess while it's easy to circumvent, it'll probably hurt a lot in a different context if it doesn't get fixed. Please note that reproducing the problem depends on the correct name of the database, which should resemble cust-a-prj-type.

      Attachments

        Issue Links

          is caused by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-15855 Assertion `mysql_table' failed in innobase_get_computed_value upon DDL/DML on a table with virtual columns

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            elenst Elena Stepanova added a comment -

            Thanks for the report. Reproducible as described.

            Here is the essential part of the test case:

            --source include/have_innodb.inc
            		 
             
            		 
            CREATE DATABASE `a-b`;
            		 
            USE `a-b`;
            		 
             
            		 
            CREATE TABLE emails (
            		 
              id INT,
            		 
              PRIMARY KEY (id)
            		 
            ) ENGINE=InnoDB;
            		 
            INSERT INTO emails VALUES (13);
            		 
             
            		 
            CREATE TABLE email_stats (
            		 
              id INT,
            		 
              email_id INT,
            		 
              date_sent DATE,
            		 
              generated_sent_date DATE GENERATED ALWAYS AS (date_sent),
            		 
              PRIMARY KEY (id),
            		 
              KEY (generated_sent_date,email_id),
            		 
              FOREIGN KEY (email_id) REFERENCES emails (id) ON DELETE SET NULL
            		 
            ) ENGINE=InnoDB;
            		 
            INSERT INTO email_stats (id, email_id, date_sent) VALUES (876,13,'1970-01-01');
            		 
             
            		 
            DELETE FROM emails;
            		 
             
            		 
            # Cleanup
            		 
            DROP DATABASE `a-b`;

            10.2 fdc4b7a6

            		 
            2021-01-12 21:35:17 140353099331328 [ERROR] [FATAL] InnoDB: Unknown error Cannot allocate memory
            		 
            210112 21:35:17 [ERROR] mysqld got signal 6 ;
            		 
             
            		 
            #5  0x00007fa686596859 in __GI_abort () at abort.c:79
            		 
            #6  0x00005630514c7691 in ib::fatal::~fatal (this=0x7fa680a0ce90, __in_chrg=<optimized out>) at /data/src/10.2/storage/innobase/ut/ut0ut.cc:649
            		 
            #7  0x00005630513f819f in row_mysql_handle_errors (new_err=0x7fa680a0d044, trx=0x7fa6815e0120, thr=0x7fa6300ab1f8, savept=0x7fa680a0d048) at /data/src/10.2/storage/innobase/row/row0mysql.cc:783
            		 
            #8  0x00005630513fab09 in row_update_for_mysql (prebuilt=0x7fa6300aa4a0) at /data/src/10.2/storage/innobase/row/row0mysql.cc:1844
            		 
            #9  0x00005630512bb69b in ha_innobase::delete_row (this=0x7fa6300ad568, record=0x7fa630036600 "\377\r") at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:9053
            		 
            #10 0x00005630510bbe04 in handler::ha_delete_row (this=0x7fa6300ad568, buf=0x7fa630036600 "\377\r") at /data/src/10.2/sql/handler.cc:6176
            		 
            #11 0x0000563051240739 in mysql_delete (thd=0x7fa630000d90, table_list=0x7fa6300127c0, conds=0x0, order_list=0x7fa630005328, limit=18446744073709551615, options=0, result=0x0) at /data/src/10.2/sql/sql_delete.cc:583
            		 
            #12 0x0000563050e2c816 in mysql_execute_command (thd=0x7fa630000d90) at /data/src/10.2/sql/sql_parse.cc:4396
            		 
            #13 0x0000563050e372fd in mysql_parse (thd=0x7fa630000d90, rawbuf=0x7fa6300126f8 "DELETE FROM emails", length=18, parser_state=0x7fa680a0e5f0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7762
            		 
            #14 0x0000563050e255f6 in dispatch_command (command=COM_QUERY, thd=0x7fa630000d90, packet=0x7fa630008b51 "DELETE FROM emails", packet_length=18, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1827
            		 
            #15 0x0000563050e240f1 in do_command (thd=0x7fa630000d90) at /data/src/10.2/sql/sql_parse.cc:1381
            		 
            #16 0x0000563050f7e4f0 in do_handle_one_connection (connect=0x563053840890) at /data/src/10.2/sql/sql_connect.cc:1336
            		 
            #17 0x0000563050f7e255 in handle_one_connection (arg=0x563053840890) at /data/src/10.2/sql/sql_connect.cc:1241
            		 
            #18 0x00005630517a5ffa in pfs_spawn_thread (arg=0x5630538238f0) at /data/src/10.2/storage/perfschema/pfs.cc:1869
            		 
            #19 0x00007fa686ab7609 in start_thread (arg=<optimized out>) at pthread_create.c:477
            		 
            #20 0x00007fa686693293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

            Reproducible on 10.2+, debug and non-debug alike.

            The failure apparently started happening in 10.2 after this commit:

            commit 8b0d4cff0760b0a35285c315d82c49631c108baf
            		 
            Author: Thirunarayanan Balathandayuthapani
            		 
            Date:   Fri Jul 6 17:13:53 2018 +0300
            		 
             
            		 
                MDEV-15855 Deadlock between purge thread and DDL statement

            elenst Elena Stepanova added a comment - Thanks for the report. Reproducible as described. Here is the essential part of the test case: --source include/have_innodb.inc   CREATE DATABASE `a-b`; USE `a-b`;   CREATE TABLE emails ( id INT , PRIMARY KEY (id) ) ENGINE=InnoDB; INSERT INTO emails VALUES (13);   CREATE TABLE email_stats ( id INT , email_id INT , date_sent DATE , generated_sent_date DATE GENERATED ALWAYS AS (date_sent), PRIMARY KEY (id), KEY (generated_sent_date,email_id), FOREIGN KEY (email_id) REFERENCES emails (id) ON DELETE SET NULL ) ENGINE=InnoDB; INSERT INTO email_stats (id, email_id, date_sent) VALUES (876,13, '1970-01-01' );   DELETE FROM emails;   # Cleanup DROP DATABASE `a-b`; 10.2 fdc4b7a6 2021-01-12 21:35:17 140353099331328 [ERROR] [FATAL] InnoDB: Unknown error Cannot allocate memory 210112 21:35:17 [ERROR] mysqld got signal 6 ;   #5 0x00007fa686596859 in __GI_abort () at abort.c:79 #6 0x00005630514c7691 in ib::fatal::~fatal (this=0x7fa680a0ce90, __in_chrg=<optimized out>) at /data/src/10.2/storage/innobase/ut/ut0ut.cc:649 #7 0x00005630513f819f in row_mysql_handle_errors (new_err=0x7fa680a0d044, trx=0x7fa6815e0120, thr=0x7fa6300ab1f8, savept=0x7fa680a0d048) at /data/src/10.2/storage/innobase/row/row0mysql.cc:783 #8 0x00005630513fab09 in row_update_for_mysql (prebuilt=0x7fa6300aa4a0) at /data/src/10.2/storage/innobase/row/row0mysql.cc:1844 #9 0x00005630512bb69b in ha_innobase::delete_row (this=0x7fa6300ad568, record=0x7fa630036600 "\377\r") at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:9053 #10 0x00005630510bbe04 in handler::ha_delete_row (this=0x7fa6300ad568, buf=0x7fa630036600 "\377\r") at /data/src/10.2/sql/handler.cc:6176 #11 0x0000563051240739 in mysql_delete (thd=0x7fa630000d90, table_list=0x7fa6300127c0, conds=0x0, order_list=0x7fa630005328, limit=18446744073709551615, options=0, result=0x0) at /data/src/10.2/sql/sql_delete.cc:583 #12 0x0000563050e2c816 in mysql_execute_command (thd=0x7fa630000d90) at /data/src/10.2/sql/sql_parse.cc:4396 #13 0x0000563050e372fd in mysql_parse (thd=0x7fa630000d90, rawbuf=0x7fa6300126f8 "DELETE FROM emails", length=18, parser_state=0x7fa680a0e5f0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7762 #14 0x0000563050e255f6 in dispatch_command (command=COM_QUERY, thd=0x7fa630000d90, packet=0x7fa630008b51 "DELETE FROM emails", packet_length=18, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1827 #15 0x0000563050e240f1 in do_command (thd=0x7fa630000d90) at /data/src/10.2/sql/sql_parse.cc:1381 #16 0x0000563050f7e4f0 in do_handle_one_connection (connect=0x563053840890) at /data/src/10.2/sql/sql_connect.cc:1336 #17 0x0000563050f7e255 in handle_one_connection (arg=0x563053840890) at /data/src/10.2/sql/sql_connect.cc:1241 #18 0x00005630517a5ffa in pfs_spawn_thread (arg=0x5630538238f0) at /data/src/10.2/storage/perfschema/pfs.cc:1869 #19 0x00007fa686ab7609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #20 0x00007fa686693293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Reproducible on 10.2+, debug and non-debug alike. The failure apparently started happening in 10.2 after this commit: commit 8b0d4cff0760b0a35285c315d82c49631c108baf Author: Thirunarayanan Balathandayuthapani Date: Fri Jul 6 17:13:53 2018 +0300   MDEV-15855 Deadlock between purge thread and DDL statement
            marko Marko Mäkelä added a comment -

            Thank you, the fix looks good to me.

            marko Marko Mäkelä added a comment - Thank you, the fix looks good to me.

            People

              thiru Thirunarayanan Balathandayuthapani
              Sebastian Maus Sebastian Maus
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.