[MDEV-24491] db_name mismatch happens during virtual column computation Created: 2020-12-26  Updated: 2021-01-19  Resolved: 2021-01-19

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Delete, Storage Engine - InnoDB
Affects Version/s: 10.4.17, 10.2, 10.3, 10.4, 10.5
Fix Version/s: 10.2.37, 10.3.28, 10.4.18, 10.5.9, 10.6.0

Type: Bug Priority: Critical
Reporter: Sebastian Maus Assignee: Thirunarayanan Balathandayuthapani
Resolution: Fixed Votes: 0
Labels: crash, delete, innodb
Environment:

Linux x86_64, on an ext4 file system, on RHEL family and Ubuntu 20.04, but probably any.

Attachments: File cust-a-prj-type.sql.gz    
Issue Links:
Problem/Incident
is caused by MDEV-15855 Assertion `mysql_table' failed in inn... Closed

 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.

 Comments   
Comment by Elena Stepanova [ 2021-01-12 ]

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

Comment by Marko Mäkelä [ 2021-01-19 ]

Thank you, the fix looks good to me.

Generated at Thu Feb 08 09:30:23 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.