Details
-
Bug
-
Status: Needs Feedback (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
MariaDB 10.11.3, Debian 6.1.38-1 x86_64, InnoDB engine, ~2M row table, collation utf8mb3_general_ci (partial conversion to utf8mb4_general_ci)
Description
*MariaDB Version:* 10.11.3
*Operating System:* Debian GNU/Linux (Kernel: 6.1.38-1)
*Architecture:* x86_64
—
*Problem:*
After changing the collation of a single CHAR(80) column in a large InnoDB table (approx. 2 million rows) from `utf8mb3_general_ci` to `utf8mb4_general_ci`, the MariaDB server started crashing repeatedly.
The crashes were triggered by a select query on that altered table. MariaDB crashed and automaticly restarted with the message:
SYSLOG
|
|
/usr/sbin/mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0x1005)[0x56057581b515]
|
/usr/sbin/mariadbd(_Z10do_commandP3THDb+0x137)[0x56057581cb27]
|
/usr/sbin/mariadbd(_Z11tp_callbackP13TP_connection+0x7c)[0x5605759debac]
|
/usr/sbin/mariadbd(+0xb9aabd)[0x560575bbdabd]
|
/usr/sbin/mariadbd(+0xc2d630)[0x560575c50630]
|
/lib/x86_64-linux-gnu/libc.so.6(+0x89044)[0x7fa2618a8044]
|
/lib/x86_64-linux-gnu/libc.so.6(+0x1095fc)[0x7fa2619285fc]
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
|
Connection ID (thread ID): 916
|
Status: NOT_KILLED
|
|
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_me
|
rge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_ke
|
ys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial
|
_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoi
|
n_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_
|
elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_m
|
aterialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_s
|
can=off,hash_join_cardinality=off
|
|
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
|
information that should help you find out what is causing the crash.
|
Writing a core file...
|
Working directory at /var/lib/mysql
|
Resource Limits:
|
Limit Soft Limit Hard Limit Units
|
Max cpu time unlimited unlimited seconds
|
Max file size unlimited unlimited bytes
|
Max data size unlimited unlimited bytes
|
Max stack size 8388608 unlimited bytes
|
Max core file size 0 unlimited bytes
|
Max resident set unlimited unlimited bytes
|
Max processes 466297 466297 processes
|
Max open files 65536 65536 files
|
Max locked memory 524288 524288 bytes
|
Max address space unlimited unlimited bytes
|
Max file locks unlimited unlimited locks
|
Max pending signals 466297 466297 signals
|
Max msgqueue size 819200 819200 bytes
|
Max nice priority 0 0
|
Max realtime priority 0 0
|
Max realtime timeout unlimited unlimited us
|
Core pattern: core
|
Additionally:
- Changing the collation back to `utf8mb3_general_ci` was extremely slow.
- The issue only appeared during select query on the altered table; everything else was unefected.
- The error suggests possible memory corruption or collation mismatch issues between table, column, or client/server.
—
*Reproduction Steps:*
1. Create a table with ~2 million rows using `utf8mb3_general_ci`:
CREATE TABLE inzeraty ( |
id INT PRIMARY KEY, |
titulek CHAR(80) COLLATE utf8mb3_general_ci, |
...
|
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8mb3_general_ci; |
2. Alter the column collation:
ALTER TABLE inzeraty MODIFY titulek CHAR(80) COLLATE utf8mb4_general_ci; |
3. Execute select:
SELECT titulek FROM TABLE |
4. MariaDB crashes shortly after.
*Context:*
- Engine: InnoDB
- Table Size: ~2 million rows
- Default Collation: `utf8mb3_general_ci`
- Modified Column: `titulek CHAR(80)` → `utf8mb4_general_ci`
- SELECT triggered crash, REVERT failed to complete in reasonable time
—
*Expected Behavior:*
MariaDB should handle collation changes and inserts gracefully without causing segmentation faults or server crashes.
—
*Additional Notes:*
- We suspect that either the collation change did not fully propagate internally, or memory structures for charset handling were corrupted.
- Crash was persistent until the table was manually restored to a prior dump.
Attachments
Issue Links
- relates to
-
MDEV-18584 Avoid copying when altering CHAR column in InnoDB table
-
- Confirmed
-