Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.11, 10.6.25
-
Can result in hang or crash
-
A invalid Mroonga INDEX comment can result in a hang of the server. This has been corrected.
Description
Originally reported in Debian as #1110683
Creating a Mroonga table with an invalid FULLTEXT index flag can make mariadbd hang.
The reproducer is:
CREATE TABLE torrent (
|
hash BINARY(20) PRIMARY KEY, |
mtime INT UNSIGNED NOT NULL,
|
stime INT UNSIGNED NOT NULL,
|
flags INT UNSIGNED NOT NULL,
|
name TEXT NOT NULL,
|
size BIGINT UNSIGNED NOT NULL,
|
fcount INT NOT NULL,
|
fnames LONGTEXT NOT NULL,
|
FULLTEXT INDEX (name)
|
COMMENT 'tokenizer "TokenBigramSplitSymbolAlphaDigit", flags "COMPRESS_ZSTD"', |
FULLTEXT INDEX (fnames)
|
COMMENT 'tokenizer "TokenBigramSplitSymbolAlphaDigit", flags "COMPRESS_ZSTD"' |
) ENGINE=Mroonga DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
|
|
COMPRESS_ZSTD is a valid column flag, but it is not a valid index flag.
Mroonga detects the invalid flag and tries to report:
The index flag 'COMPRESS_ZSTD' is invalid. It is ignored
However, the CREATE TABLE statement never returns. In the reported case, mariadbd had to be killed forcefully after a normal restart did not complete.
After the forced termination, the SQL table was not visible as expected, but Groonga side objects had already been created. Re-running the same CREATE TABLE then failed because the Groonga database object already existed.
A gdb backtrace from the stuck server shows the thread repeatedly going through push_warning_printf() from mrn_parse_grn_index_column_flags(), called while creating the Mroonga indexes.
The issue seems to be in the invalid index flag handling. The DDL gets stuck and a forced kill can leave Groonga-side metadata behind.