Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-37234

MariaDB crash after altering column collation from utf8mb3_general_ci to utf8mb4_general_ci

    XMLWordPrintable

Details

    • Bug
    • Status: Needs Feedback (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • 10.11
    • Server
    • 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

          Activity

            People

              alice Alice Sherepa
              jakub_fajnskupina Jakub Skoda
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.