[MDEV-23245] Still getting assertion failure in file data0type.cc line 67 - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: 10.4.13
Fix Version/s: 10.4.14, 10.5.5
Component/s: Storage Engine - InnoDB
Labels:
None

Description

This error is essentially the same as ~~MDEV-20726~~, except that is still happens for me. I'm running mariadb server version 10.4.13-MariaDB-1:10.4.13+maria~bionic.

Here is a very short example which reproduces the error (Careful - crashes the server and prevents it from restarting!)

CREATE TABLE `Foo`

    `Bar` char(2) CHARACTER SET utf8,

    KEY `Bar` (`Bar`(1))

) ENGINE = InnoDB;

ALTER TABLE `Foo` MODIFY `Bar` char(2) CHARACTER SET utf8mb4;

INSERT INTO Foo VALUES ('a');

At this point the server crashes and cannot restart, always crashing again with the error message "InnoDB: Failing assertion: !(prefix_len % mbmaxlen)".

Observations: The error only occurs if the index is a prefix index. It also doesn't occur if the collation is changed in the ALTER TABLE - going from utf8_bin to utf8mb4_bin triggers the bug, as does going from utf8_general_ci to utf8mb4_general_ci, but when going from utf8_general_ci to utf8mb4_bin it does not occur.

Attachments

Issue Links

is duplicated by

MDEV-22898 SQL query always crashes on INSERT IGNORE

Closed

MDEV-24419 Galera crash after ALTER TABLE convert to utf8mb4: Assertion failure in file data0type.cc line 67

Closed

relates to

MDEV-20726 InnoDB: Assertion failure in file data0type.cc line 67

Closed

MDEV-23964 MariaDB 10.5.4 and 10.5.6 replica keeps crashing when the a 10.2.x master run a `ALTER TABLE CHARACTER utf8mb4`

Closed

Activity

Ascending order - Click to sort in descending order

Marko Mäkelä added a comment - 2020-07-21 14:45

I can repeat a debug assertion failure, even after recently fixing ~~MDEV-22771~~.

10.4 b1538f4d60bf30de00417a7c3f948d2de654fcb3

mysqld: /mariadb/10.4/storage/innobase/data/data0type.cc:64: ulint dtype_get_at_most_n_mbchars(ulint, ulint, ulint, ulint, ulint, const char *): Assertion `!mbmaxlen || !(prefix_len % mbmaxlen)' failed.

Marko Mäkelä added a comment - 2020-07-21 14:45 I can repeat a debug assertion failure, even after recently fixing MDEV-22771 . 10.4 b1538f4d60bf30de00417a7c3f948d2de654fcb3 mysqld: /mariadb/10.4/storage/innobase/data/data0type.cc:64: ulint dtype_get_at_most_n_mbchars(ulint, ulint, ulint, ulint, ulint, const char *): Assertion `!mbmaxlen || !(prefix_len % mbmaxlen)' failed.

Marko Mäkelä added a comment - 2020-07-21 15:11

I see nothing wrong in ha_innobase::can_convert_string(), but I do see a problem that ha_innobase::check_if_supported_inplace_alter() is only invoked with ha_alter_info->handler_flags = HA_INPLACE_ADD_UNIQUE_INDEX_NO_WRITE | ALTER_COLUMN_TYPE_CHANGE_BY_ENGINE.
Any column prefix indexes on the CHAR column must be rebuilt.
I tried a few variations of the test:

--source include/have_innodb.inc

CREATE TABLE Foo

  Bar char(2) CHARACTER SET utf8,

  KEY Bar (Bar

#(1)

) ENGINE = InnoDB;

ALTER TABLE Foo MODIFY Bar char(2) CHARACTER SET utf8mb4;

#--source include/restart_mysqld.inc

#ALTER TABLE Foo ADD lb INT GENERATED ALWAYS AS (length(Bar));

INSERT INTO Foo SET Bar='a';

DROP TABLE Foo;

With the (1) commented out, the test completes successfully. Similarly, if I declare the column as varchar(2) instead of char(2), everything seems to be fine. Also ROW_FORMAT=REDUNDANT seems to be fine.

The commented-out statements are causing the table to be evicted and re-loaded into InnoDB dict_sys. That does not affect the reproducibility.

Marko Mäkelä added a comment - 2020-07-21 15:11 I see nothing wrong in ha_innobase::can_convert_string() , but I do see a problem that ha_innobase::check_if_supported_inplace_alter() is only invoked with ha_alter_info->handler_flags = HA_INPLACE_ADD_UNIQUE_INDEX_NO_WRITE | ALTER_COLUMN_TYPE_CHANGE_BY_ENGINE . Any column prefix indexes on the CHAR column must be rebuilt. I tried a few variations of the test: --source include/have_innodb.inc CREATE TABLE Foo ( Bar char (2) CHARACTER SET utf8, KEY Bar (Bar #(1) ) ) ENGINE = InnoDB; ALTER TABLE Foo MODIFY Bar char (2) CHARACTER SET utf8mb4; # --source include/restart_mysqld.inc # ALTER TABLE Foo ADD lb INT GENERATED ALWAYS AS (length(Bar)); INSERT INTO Foo SET Bar= 'a' ; DROP TABLE Foo; With the (1) commented out, the test completes successfully. Similarly, if I declare the column as varchar(2) instead of char(2) , everything seems to be fine. Also ROW_FORMAT=REDUNDANT seems to be fine. The commented-out statements are causing the table to be evicted and re-loaded into InnoDB dict_sys . That does not affect the reproducibility.

Simeon Maxein added a comment - 2020-07-21 15:29 - edited

For me this also happens if both the initial column definition and the ALTER TABLE specify varchar (though not if one of them specifies varchar and the other char)

Simeon Maxein added a comment - 2020-07-21 15:29 - edited For me this also happens if both the initial column definition and the ALTER TABLE specify varchar (though not if one of them specifies varchar and the other char)

People

Assignee:: Eugene Kosov (Inactive)

Reporter:: Simeon Maxein

Votes:: 0 Vote for this issue

Watchers:: 4 Start watching this issue

Dates

Created:: 2020-07-21 14:33

Updated:: 2020-12-16 14:36

Resolved:: 2020-07-29 03:13

Git Integration

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

MariaDB Server