InnoDB assertion result != FTS_INVALID (fts0fts.cc:2190) on the second UPDATE after ROLLBACK TO SAVEPOINT of a FULLTEXT-indexed row locked FOR UPDATE

Summary

On MariaDB 11.8.9, an InnoDB table with a FULLTEXT index crashes the server with an assertion (signal 6). The sequence, in one transaction:
1. a locking read (SELECT … FOR UPDATE);
2. an update of the indexed column;
3. a rollback to a savepoint taken before that update;
4. a second update of the same row.
The assertion fires during the second UPDATE. Without the locking read the transaction commits normally. No system-versioned table is involved.

Environment

• Server: MariaDB 11.8.9, the official Docker image mariadb@sha256:79d59758afc91b89b120b0a8904d637f5a3b3e1c4900f29b740d6d46c72fef68. Source revision bf9193a939f515e95dd8def1a5468088c91cede6.
• Storage engine: InnoDB, default settings.
• No WITH SYSTEM VERSIONING on any table.

Steps to reproduce

CREATE DATABASE repro;

USE repro;

CREATE TABLE t (

  id INT PRIMARY KEY,

  body TEXT,

  FULLTEXT KEY ft_body (body)

) ENGINE=InnoDB;

INSERT INTO t VALUES (1, 'alpha beta gamma');

START TRANSACTION;

SELECT * FROM t WHERE id = 1 FOR UPDATE;      -- locking read

SAVEPOINT s1;

UPDATE t SET body = 'delta epsilon' WHERE id = 1;

ROLLBACK TO SAVEPOINT s1;

UPDATE t SET body = 'zeta eta' WHERE id = 1;   -- the server asserts during this statement

COMMIT;

The same script without the SELECT … FOR UPDATE line does not assert, and the COMMIT succeeds.

Actual result

InnoDB: Assertion failure in file ./storage/innobase/fts/fts0fts.cc line 2190

InnoDB: Failing assertion: result != FTS_INVALID

[ERROR] mariadbd got signal 6 ;

The failing function is fts_trx_row_get_new_state.

Stack trace (the mariadbd( frames, as printed):

mariadbd(my_print_stacktrace+0x30)

mariadbd(handle_fatal_signal+0x1ef)

mariadbd(+0x64738e)

mariadbd(+0x66efb9)

mariadbd(+0xf98427)

mariadbd(+0xdb49cb)

mariadbd(+0xdb4b98)

mariadbd(+0xd25546)

mariadbd(_ZN7handler13ha_update_rowEPKhS1_+0xe2)

mariadbd(_ZN14Sql_cmd_update19update_single_tableEP3THD+0x1eb0)

mariadbd(_ZN14Sql_cmd_update13execute_innerEP3THD+0x11d)

mariadbd(_ZN11Sql_cmd_dml7executeEP3THD+0x12e)

mariadbd(_Z21mysql_execute_commandP3THDb+0x1182)

mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x1cd)

mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0x19f3)

mariadbd(_Z10do_commandP3THDb+0x1e8)

mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x1e3)

mariadbd(handle_one_connection+0x71)

Expected result: the transaction commits, and the FULLTEXT index reflects 'zeta eta'.

Related issues, and why this one differs

• MDEV-30455 (closed as a duplicate, no fix version): the same assertion, reached through REPLACE twice on a system-versioned table. Our table is not versioned, and our path is a savepoint rollback, not REPLACE.
• MDEV-38156 (a duplicate of MDEV-30455; reported on 11.8.5, 12.0.2 and 12.2.1; no fix version): the same versioned-table path.
• MDEV-30028: the same assertion on a system-versioned table.
• MDEV-34057 (fixed in 11.4.3): a FULLTEXT issue with no assertion. It does not match.
• The release notes for 11.8.4, 11.8.6 and 11.8.7 name no fix for this assertion. 11.8.9 is the newest 11.8 release.

Why ours may matter: the existing reports tie the assertion to system versioning. This reproduction uses a fresh, non-versioned table. A locking read, a savepoint rollback of a FULLTEXT-indexed column, and a second change of the same row are enough. Without the locking read, it does not assert. This suggests the FTS row-state transition after ROLLBACK TO SAVEPOINT on a row locked before the savepoint may be the common cause.

Workaround

FULLTEXT search on the affected table is switched off until a fixed release ships.