Details
-
Bug
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.11.11
-
None
-
None
-
None
-
Can result in hang or crash
Description
Environment Details
Product: MariaDB Server
Version: 10.11.11-MariaDB-log (Community / Enterprise – confirm as applicable)
OS: Red Hat Enterprise Linux release 8.6 (Ootpa).
Architecture: x86_64
Deployment Type: Replication Slave (read_only=ON)
Workload: High-concurrency OLTP (application-driven queries)
Background
We previously faced frequent MariaDB crashes with Signal 11 (SIGSEGV) on MariaDB 10.11.5.
Based on MariaDB recommendation, we upgraded to version 10.11.11.
However, despite the upgrade, the MariaDB service crashed again on 29-Jan-2026 at ~03:30, with the same SIGSEGV (signal 11) symptom.
This ticket is to request deep analysis of the crash, including validation of a possible SQL parser defect or memory corruption issue.
Crash Summary
Crash Time: 29-Jan-2026 ~03:30
Signal: SIGSEGV (signal 11)
Process: /usr/sbin/mariadbd
Core Dump: Generated successfully
Restart: Manual restart required
MariaDB error log excerpt:
/usr/sbin/mariadbd got signal 11
Server Version: 10.11.11-MariaDB-log
GDB / Core Dump Analysis (Key Findings)
Core dump was analyzed using MariaDB debuginfo.
Crash Location
The segmentation fault occurs inside the SQL parser during client query processing:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 handle_fatal_signal()
#1 my_write_core()
#2 MYSQLparse() at sql/sql_yacc.yy:9116
#3 parse_sql()
#4 mysql_parse()
#5 dispatch_command(COM_QUERY)
#6 do_command()
#7 do_handle_one_connection()
Important Observations
Crash occurred while handling COM_QUERY
Failure happens before execution, during query parsing
Query length at time of crash: ~1293 bytes
Parser context includes a long select-list style SQL (column list with many custom fields)
This indicates the crash is not related to InnoDB recovery, redo logs, or replication SQL thread, but triggered during SQL parsing of a client query.
Replication / InnoDB Status
No InnoDB corruption detected
No redo/undo recovery failure
No assertion failures logged
Replication issues seen after restart are a side-effect and not the crash trigger
Configuration Highlights
read_only=ON
innodb_file_per_table=1
innodb_flush_log_at_trx_commit=1
core-file enabled
No custom plugins loaded
Full my.cnf attached for reference.
Attachments Provided
MariaDB error log at time of crash
Core dump backtrace (gdb bt full)
Full MariaDB configuration (my.cnf)
(Additional OS debuginfo can be provided if required.)
Support Request
We request MariaDB Support to:
Analyze the provided core dump and backtrace
Confirm whether this crash matches:
A known SQL parser defect in 10.11.x, or
A memory corruption scenario triggered by a specific query pattern
Advise:
If a hotfix or newer 10.11.x build addresses this issue
If specific workarounds or configuration changes are recommended
Whether the failing SQL pattern can be isolated or mitigated
Business Impact
Unexpected database crash
Service disruption requiring manual intervention
High risk due to recurrence even after recommended upgrade