1
0
mirror of https://github.com/MariaDB/server.git synced 2026-10-23 18:49:29 +03:00
Files
mariadb/sql
Aleksey Midenkov 26823fe344 MDEV-39074 trans_rollback_stmt(THD *): Assertion `! thd->in_sub_stmt' failed.
slave_close_thread_tables() unconditionally called
trans_commit_stmt()/trans_rollback_stmt(), which assert
!thd->in_sub_stmt. A BINLOG statement with malformed base64 payload
executed from an AFTER INSERT trigger hits this: on decode failure,
mysql_client_binlog_statement() sets thd->is_error() and calls
slave_close_thread_tables() from within the trigger's sub-statement.

The fix refuses BINLOG in stored routines, triggers, events and
anonymous blocks with ER_SP_BADSTATEMENT at parse time, like LOCK,
HANDLER etc. Dynamic SQL (EXECUTE IMMEDIATE, EXECUTE) run from a
routine bypasses the parser check, so mysql_client_binlog_statement()
checks spcont as well: in a stored procedure in_sub_stmt is 0, but the
decoded events assert !spcont in reset_for_next_command().

1. BINLOG statement executed from a trigger, SF or SP is disabled
by the patch:

Row events (Rows_log_event) open their target table via a
one-shot check that only fires at the top of a fresh statement.
Inside a trigger, the table is never opened this way. It may be
fixed by reusing query_tables, but:

  - find_locked_table() matches only by table name -- it could return
    the TABLE instance the enclosing statement is actively writing
    through, not an idle one. Reusing it would require pre-saving its
    state: record[0]/bitmaps/handler/etc. (and would bypass
    ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG)

  - set_stmt_row_injection()/set_time() calls would mutate thd->lex,
    which at that point is main_lex -- shared with the enclosing
    statement, not something safe to touch.

Statement events (Query_log_event) run the embedded query via
mysql_parse(): it bundles lex_start(), reset_for_next_command() and
parse_sql() as one unit meant for a genuinely new top-level statement,
not a one-off nested parse.

Calling parse_sql() directly instead avoids that, but then we own
everything mysql_parse() was doing for us: a private LEX and a
private Query_arena (or allocations land on main_lex/whatever arena
is currently active, shared with the enclosing statement), plus
calling mysql_execute_command() ourselves afterwards.

In any case, DML for query_tables cannot be done due to
ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG reasons explained above.

2. PS for BINLOG statement still works and needs a leak fix for
statement events:

A BINLOG statement decoding to a Query_log_event, executed via
PREPARE/EXECUTE, leaked its nested query's allocations onto the PS's
own persistent arena: thd->stmt_arena pointed at it while mysql_parse()
ran the decoded query. Second EXECUTE asserted on ROOT_FLAG_READ_ONLY,
since PROTECT_STATEMENT_MEMROOT marks that arena read-only after a
successful execution.

The fix redirects thd->stmt_arena to thd itself for the duration of
the event application, so stmt_arena->is_conventional() reads
true and activate_stmt_arena_if_needed() (called e.g. from
save_leaf_tables()) never redirects allocations to the PS's arena in
the first place.

Harmless for what it's protecting: leaf_tables_exec is normally cached
on the persistent arena so a repeatedly-executed statement's
SELECT_LEX doesn't rebuild it every time, but our SELECT_LEX is torn
down and reparsed fresh (due to mysql_parse() semantics) on every
EXECUTE, so there's nothing to cache here regardless of which arena is
used.
2026-10-15 19:58:38 +03:00
..
…
2026-07-23 11:12:27 +02:00
2026-07-23 11:12:27 +02:00
…
2025-09-04 18:08:39 +03:00
2024-01-17 13:35:05 +02:00
…
…
2023-01-27 13:54:14 +01:00
2024-11-29 13:43:17 +02:00
2024-11-29 12:37:46 +02:00
2024-10-29 15:24:38 +01:00
…
2025-09-04 18:08:39 +03:00
2023-12-17 11:20:43 +01:00
…
…
…
2025-02-27 04:02:33 +01:00
2025-09-04 18:08:39 +03:00
2024-11-29 13:43:17 +02:00
…
…
2024-11-29 13:43:17 +02:00
2024-12-05 10:11:58 +01:00
2026-08-19 08:13:54 +02:00
2026-01-28 14:22:20 +01:00
2026-01-28 14:22:20 +01:00
2026-01-28 14:22:20 +01:00
2026-01-28 14:22:20 +01:00
2026-07-23 11:12:27 +02:00
2026-01-28 14:22:20 +01:00
2024-11-29 13:43:17 +02:00
2023-11-08 16:23:30 +01:00
…
2024-06-27 10:26:09 +03:00
2024-06-24 13:09:47 +03:00
…
…
2025-09-04 18:08:39 +03:00
…
2023-11-08 16:23:30 +01:00
2026-08-19 08:13:54 +02:00
2023-10-14 13:36:11 +03:00
2026-01-28 14:22:20 +01:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2023-02-10 13:43:53 +02:00
2026-04-20 11:07:30 +03:00
2023-12-18 11:19:04 +01:00
2024-11-29 12:37:46 +02:00
…
2024-06-24 13:09:47 +03:00
2023-03-24 12:54:05 +11:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2024-07-22 15:14:50 +02:00
2026-06-15 10:43:23 +02:00
2026-06-15 10:43:23 +02:00
2025-10-28 17:49:51 +01:00
2025-10-28 17:49:51 +01:00
2026-07-23 11:12:27 +02:00
2024-11-29 12:37:46 +02:00
2026-08-19 08:13:54 +02:00
2025-09-04 18:08:39 +03:00
2025-01-10 13:14:42 +01:00
2024-06-24 13:09:47 +03:00
2025-01-30 11:55:13 +01:00
2025-01-30 11:55:13 +01:00
2023-07-10 11:22:21 +03:00
2024-11-29 13:43:17 +02:00
2024-11-29 13:43:17 +02:00
2026-08-19 08:13:54 +02:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2024-11-23 08:14:22 -07:00
2026-01-02 11:06:05 +02:00
2026-07-23 11:12:27 +02:00
2026-07-23 11:12:27 +02:00
2026-03-17 18:57:42 +01:00
2026-01-28 14:22:20 +01:00
…
2024-08-20 10:00:39 +02:00
2025-09-04 18:08:39 +03:00
2024-06-27 10:26:09 +03:00
2024-11-29 12:37:46 +02:00
…
2025-09-19 12:31:14 +03:00
2025-09-04 18:08:39 +03:00
2023-05-23 12:25:39 +03:00
2024-06-11 12:50:10 +03:00
2024-04-15 18:54:30 +02:00
2026-01-28 14:22:20 +01:00
2024-07-03 12:45:30 +02:00
2023-08-04 08:01:06 +02:00
2026-07-23 11:12:27 +02:00
2023-12-17 11:20:43 +01:00
2026-07-23 11:12:27 +02:00
2023-12-02 01:02:50 +01:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2026-03-17 11:05:34 +02:00
2024-03-27 15:00:56 +02:00
2025-09-04 18:08:39 +03:00
2026-07-23 11:12:27 +02:00
2025-01-20 09:57:37 +02:00
2025-03-27 08:01:47 +02:00
2023-09-25 13:06:57 +10:00
2024-01-18 19:22:23 +02:00
2023-08-01 15:08:52 +02:00
2024-11-23 08:14:22 -07:00
2024-11-23 08:14:23 -07:00
2026-08-19 08:13:54 +02:00
2026-07-23 11:12:27 +02:00
2026-07-23 11:12:27 +02:00
2024-01-10 18:01:46 +11:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2024-06-24 13:09:47 +03:00
…
2025-09-04 18:08:39 +03:00
2023-02-10 12:02:11 +02:00
2024-11-29 13:43:17 +02:00
2024-01-02 17:37:58 +02:00
2024-06-27 10:26:09 +03:00
2026-06-21 15:32:20 +02:00
2024-01-03 15:37:57 +02:00
2024-10-03 10:55:08 +03:00
2026-07-23 11:12:27 +02:00
2026-07-23 11:12:27 +02:00
2026-06-21 15:32:20 +02:00