Analysis of MySQL 8.0.26 Crash Caused by the terminology_use_previous Parameter and INFORMATION_SCHEMA.PROCESSLIST Access

Background: To meet security requirements, a client upgraded MySQL to version 8.0.26, which introduced incompatible terminology changes. MySQL provides the system variable terminology_use_previous ; setting it to BEFORE_8_0_26 preserves legacy terms such as master and slave .

Incompatible Change: From MySQL 8.0.26, new aliases or replacement names are provided for most remaining identifiers that contain the terms “master”, which is changed to “source”; “slave”, which is changed to “replica”; and “mts” (for “multithreaded slave”), which is changed to “mta”.
If the incompatible changes do have an impact for you, you can set the new system variable terminology_use_previous to BEFORE_8_0_26 to make MySQL Server use the old versions of the names.

After the upgrade, normal monitoring caused frequent MySQL crashes. The crash logs show the last executed statement was select * from information_schema.processlist . The stack trace reveals a C++ logic error: basic_string::_S_construct null not valid , leading to an abort.

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid
… (full stack trace omitted for brevity) …
Query (7f9924019488): select * from information_schema.processlist

Further investigation showed that disabling the terminology_use_previous parameter (setting it to NONE ) prevents the crash, indicating the parameter configuration is the root cause. Two key findings emerged:

The variable terminology_use_previous must be set to BEFORE_8_0_26 .

A query against the PROCESSLIST table must be performed.

Accessing INFORMATION_SCHEMA.PROCESSLIST holds a global mutex, which can affect performance but should not cause a crash. MySQL offers performance_schema_show_processlist to use a lock‑free implementation based on performance_schema.threads . Enabling this variable together with terminology_use_previous=BEFORE_8_0_26 still reproduces the crash, while querying performance_schema.threads does not.

The default SHOW PROCESSLIST implementation iterates across active threads while holding a global mutex. The alternative implementation queries the Performance Schema processlist table and does not require a mutex.

Searching MySQL bug reports revealed no direct bug until the 8.0.27 release notes, which mention that concurrent access to INFORMATION_SCHEMA.PROCESSLIST can cause a failure (Bug #32625376). Reproducing the issue on both 8.0.26 and 8.0.27 confirmed the problem persists.

The author reported the bug to MySQL, receiving confirmation that it will be fixed in the upcoming 8.0.28 release.

Summary of findings:

The crash is linked to the terminology change and the use of INFORMATION_SCHEMA.PROCESSLIST under the BEFORE_8_0_26 setting.

For monitoring, prefer querying performance_schema.threads to avoid the global mutex.

Limit the frequency of processlist queries, especially on busy systems.

The issue is recognized as an internal MySQL bug and will be addressed in version 8.0.28.