Intermittent SIGSEGV in JOIN::free_pushdown_handlers() during query cleanup on simple single-table SELECTs

Server crashes intermittently (2-4 times/day) with SIGSEGV during normal
production traffic. The crash is NOT limited to complex queries - it occurs
on simple single-table SELECT statements with no joins or subqueries, e.g.:

SELECT * FROM modules WHERE module = 'itemshop' ORDER BY regdate ASC LIMIT 1
SELECT * FROM documents WHERE document_srl = '17591003'
SELECT * FROM timeline_registered_info WHERE module_srl = '30628'

Since the crashing queries vary across different tables and are trivially
simple, this does not appear to be data corruption or a specific query
pattern bug, but rather a bug in the generic JOIN cleanup path that every
query goes through.

Full gdb backtrace (with MariaDB-server-debuginfo installed) of the crashing
thread:

#0 JOIN::free_pushdown_handlers (this=this@entry=0x77adf0016048, join_list=...) at sql/sql_select.cc:17295
#1 JOIN::cleanup (this=0x77adf0016048, full=full@entry=true) at sql/sql_select.cc:17262
#2 JOIN::join_free (this=this@entry=0x77adf0016048) at sql/sql_select.cc:17088
#3 do_select (procedure=<optimized out>, join=0x77adf0016048) at sql/sql_select.cc:23950
#4 JOIN::exec_inner (this=0x77adf0016048) at sql/sql_select.cc:5112
#5 JOIN::exec (this=this@entry=0x77adf0016048) at sql/sql_select.cc:4900
#6 mysql_select (...) at sql/sql_select.cc:5426
#7 handle_select (...) at sql/sql_select.cc:634
#8 execute_sqlcom_select (...) at sql/sql_parse.cc:6232
#9 mysql_execute_command (...) at sql/sql_parse.cc:4014
#10 mysql_parse (...) at sql/sql_parse.cc:7953
#11 dispatch_command (command=COM_QUERY, ...) at sql/sql_class.h:1683

This issue persisted after upgrading from 11.4.12 to 11.8.8 (crash frequency
dropped from ~7.6/day to ~2.7/day, but did not disappear).

PDO client-side emulated prepared statements (PDO::ATTR_EMULATE_PREPARES=true)
were tried as a workaround, ruling out the server-side prepared statement
protocol as the cause - crashes occur identically via plain COM_QUERY text
protocol.

Note: `modules`, `documents`, and `timeline_registered_info` are core tables
from the open-source Rhymix CMS (github.com/rhymix/rhymix), not custom/private
tables. The specific value 'itemshop' in the first query is just example data
(the name of one installed module) and has no bearing on the crash - the same
crash occurs across three structurally different tables, suggesting the bug is
in the generic JOIN cleanup path rather than tied to any specific table/data.

Table schemas (table prefix omitted):

CREATE TABLE `modules` (
`module_srl` bigint(11) NOT NULL,
`module` varchar(80) NOT NULL,
`module_category_srl` bigint(11) DEFAULT 0,
`layout_srl` bigint(11) DEFAULT 0,
`use_mobile` char(1) DEFAULT 'N',
`mlayout_srl` bigint(11) DEFAULT 0,
`menu_srl` bigint(11) DEFAULT 0,
`site_srl` bigint(11) NOT NULL DEFAULT 0,
`domain_srl` bigint(20) NOT NULL DEFAULT -1,
`mid` varchar(40) NOT NULL,
`skin` varchar(250) DEFAULT NULL,
`mskin` varchar(250) DEFAULT NULL,
`browser_title` varchar(250) NOT NULL,
`description` text DEFAULT NULL,
`is_default` char(1) NOT NULL DEFAULT 'N',
`content` longtext DEFAULT NULL,
`mcontent` longtext DEFAULT NULL,
`open_rss` char(1) NOT NULL DEFAULT 'Y',
`header_text` text DEFAULT NULL,
`footer_text` text DEFAULT NULL,
`regdate` varchar(14) DEFAULT NULL,
`is_skin_fix` char(1) DEFAULT 'N',
`is_mskin_fix` char(1) DEFAULT 'N',
PRIMARY KEY (`module_srl`),
UNIQUE KEY `unique_mid` (`mid`),
KEY `idx_module` (`module`),
KEY `idx_module_category` (`module_category_srl`),
KEY `idx_domain_srl` (`domain_srl`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci

CREATE TABLE `documents` (
`document_srl` bigint(11) NOT NULL,
`module_srl` bigint(11) NOT NULL DEFAULT 0,
`category_srl` bigint(11) NOT NULL DEFAULT 0,
`lang_code` varchar(10) NOT NULL DEFAULT '',
`is_notice` char(1) NOT NULL DEFAULT 'N',
`title` varchar(250) DEFAULT NULL,
`title_bold` char(1) NOT NULL DEFAULT 'N',
`title_color` varchar(7) DEFAULT NULL,
`content` longtext NOT NULL,
`readed_count` bigint(11) NOT NULL DEFAULT 0,
`voted_count` bigint(11) NOT NULL DEFAULT 0,
`blamed_count` bigint(11) NOT NULL DEFAULT 0,
`comment_count` bigint(11) NOT NULL DEFAULT 0,
`trackback_count` bigint(11) NOT NULL DEFAULT 0,
`uploaded_count` bigint(11) NOT NULL DEFAULT 0,
`password` varchar(60) DEFAULT NULL,
`user_id` varchar(80) DEFAULT NULL,
`user_name` varchar(80) NOT NULL,
`nick_name` varchar(80) NOT NULL,
`member_srl` bigint(11) NOT NULL,
`email_address` varchar(250) NOT NULL,
`homepage` varchar(250) NOT NULL,
`tags` text DEFAULT NULL,
`extra_vars` text DEFAULT NULL,
`regdate` varchar(14) DEFAULT NULL,
`last_update` varchar(14) DEFAULT NULL,
`last_updater` varchar(80) DEFAULT NULL,
`ipaddress` varchar(128) NOT NULL,
`list_order` bigint(11) NOT NULL,
`update_order` bigint(11) NOT NULL,
`allow_trackback` char(1) NOT NULL DEFAULT 'Y',
`notify_message` char(1) NOT NULL DEFAULT 'N',
`reward_point` bigint(11) DEFAULT NULL,
`reward_srl` bigint(11) DEFAULT NULL,
`status` varchar(20) DEFAULT 'PUBLIC',
`comment_status` varchar(20) DEFAULT 'ALLOW',
PRIMARY KEY (`document_srl`),
KEY `idx_module_srl` (`module_srl`),
KEY `idx_category_srl` (`category_srl`),
KEY `idx_is_notice` (`is_notice`),
KEY `idx_member_srl` (`member_srl`),
KEY `idx_regdate` (`regdate`)
– (additional composite indexes omitted for brevity)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci

CREATE TABLE `timeline_registered_info` (
`module_srl` bigint(20) NOT NULL,
`notice` char(1) NOT NULL DEFAULT 'N',
`replace` char(1) NOT NULL DEFAULT 'N',
`write` char(1) NOT NULL DEFAULT 'N',
`title` text DEFAULT NULL,
`content` text DEFAULT NULL,
`tags` text DEFAULT NULL,
`readed_count` bigint(20) NOT NULL DEFAULT 0,
`voted_count` bigint(20) NOT NULL DEFAULT 0,
`blamed_count` bigint(20) NOT NULL DEFAULT 0,
`comment_count` bigint(20) NOT NULL DEFAULT 0,
`popular_count` bigint(20) NOT NULL DEFAULT 0,
`standard_date` varchar(14) DEFAULT NULL,
`limit_date` varchar(14) DEFAULT NULL,
`auto_renewal` char(1) NOT NULL DEFAULT 'N',
`regdate` varchar(14) DEFAULT NULL,
PRIMARY KEY (`module_srl`),
KEY `idx_standard_date` (`standard_date`),
KEY `idx_limit_date` (`limit_date`),
KEY `idx_regdate` (`regdate`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_unicode_ci

Additional gdb inspection of a coredump (another crash instance, not one of
the three example queries above - this one on a query touching table
`itemshop_transaction`):

(gdb) thread 5
(gdb) frame 0
#0 JOIN::free_pushdown_handlers (this=this@entry=0x77adf0016048, join_list=...)
at sql/sql_select.cc:17295
17295 table_ref->dt_handler= NULL;

(gdb) print table_ref
$3 = (TABLE_LIST *) 0x77adf0014b88

(gdb) print *table_ref
(full struct printed successfully - table_ref is a VALID, readable pointer)
Relevant fields:
db = "rxdb"
table_name = "RXDB_itemshop_transaction"
alias = "itemshop_transaction"
nested_join = 0x0 (not a nested join - confirms simple query)
dt_handler = 0x0 (already NULL/inactive)
pushdown_derived = 0x0 (already NULL/inactive)
derived = 0x0 (not a derived table)

Relevant source (sql/sql_select.cc:17281-17296):

void JOIN::free_pushdown_handlers(List<TABLE_LIST>& join_list)
{
List_iterator<TABLE_LIST> li(join_list);
TABLE_LIST *table_ref;
while ((table_ref= li++))
{
if (table_ref->nested_join)
free_pushdown_handlers(table_ref->nested_join->join_list);
if (table_ref->pushdown_derived)

delete table_ref->dt_handler;
table_ref->dt_handler= NULL; // <-- crash reported here
}
}

Observation: table_ref itself resolves to fully valid, readable memory, and
neither dt_handler nor pushdown_derived were active for this table (both
already NULL) - this table isn't using any pushdown feature at all. This
suggests the crash may not be a logic bug specific to pushdown handling, but
rather memory corruption originating elsewhere (e.g. in join_list's linked-
list structure/iterator, or a stale/reused table_ref) that happens to
manifest here since this is a code path every query passes through during
cleanup.