Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.4.17, 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
-
Linux x86_64, on an ext4 file system, on RHEL family and Ubuntu 20.04, but probably any.
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
-
-
- Closed
-