Lost connection to MySQL server during query – Assertion failure: ddl0buffer.cc:204:ptr

Lost connection to MySQL server during query – Assertion failure: ddl0buffer.cc:204:ptr

When importing a dump file from MariaDB to MySQL the following error appears and forces MySQL service to restart:

ERROR 2013 (HY000) at line 2286533: Lost connection to MySQL server during query

error in MySQL error log file:

2022-02-02T12:07:43.397210Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: ddl0buffer.cc:204:ptr < bounds.second thread 139877533333248
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:07:43 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x1f8622d]
/usr/sbin/mysqld(handle_fatal_signal+0x32b) [0xfecfbb]
/lib64/libpthread.so.0(+0xf630) [0x7f389d0a1630]
/lib64/libc.so.6(gsignal+0x37) [0x7f389b357387]
/lib64/libc.so.6(abort+0x148) [0x7f389b358a78]
/usr/sbin/mysqld() [0xd37acb]
/usr/sbin/mysqld(ddl::Key_sort_buffer::serialize(std::pair<unsigned char*, unsigned long>, std::function<dberr_t (std::pair<unsigned char*, unsigned long>, unsigned long&)>&&)+0x3b0) [0x2414410]
/usr/sbin/mysqld(ddl::Builder::bulk_add_row(ddl::Cursor&, ddl::Row&, unsigned long, std::function<dberr_t ()>&&)+0x1d8) [0x241d848]
/usr/sbin/mysqld(ddl::Builder::add_row(ddl::Cursor&, ddl::Row&, unsigned long, std::function<dberr_t ()>&&)+0xa5) [0x241dcd5]
/usr/sbin/mysqld() [0x23730c1]
/usr/sbin/mysqld(Parallel_reader::Ctx::traverse_recs(PCursor*, mtr_t*)+0x4c6) [0x2196a06]
/usr/sbin/mysqld(Parallel_reader::Ctx::traverse()+0x197) [0x21988d7]
/usr/sbin/mysqld(Parallel_reader::worker(Parallel_reader::Thread_ctx*)+0x2d5) [0x219e055]
/usr/sbin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Detached_thread, void (Parallel_reader::*)(Parallel_reader::Thread_ctx*), Parallel_reader*, Parallel_reader::Thread_ctx*> > >::_M_run()+0xd3) [0x2194ea3]
/usr/sbin/mysqld() [0x2788dcf]
/lib64/libpthread.so.0(+0x7ea5) [0x7f389d099ea5]
/lib64/libc.so.6(clone+0x6d) [0x7f389b41fb0d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

In the .sql dump file the line where error occurs is 2286533 and contains:

ALTER TABLE 'wp_options'

This table is in InnoDB but by changing the engine to MyISAM import works.

On the official MySQL website, there is a bug report with this error that is not publically visible because the author selected the “Does this bug report represent a security vulnerability?” option when reporting the bug, meaning that It can be used as an exploit. That’s quite understandable because on a shared server single user can restart mysqld service with a simple db import causing problems to all other users.

On MariaDB import succeeded so the problem appears to affect only MySQL servers.

Stefan Pejcic
Join the discussion

I enjoy constructive responses and professional comments to my posts, and invite anyone to comment or link to my site.