Bug #110086 SIGSEGV in do_apply_event (row_upd_store_row -> innobase_get_computed_value)
Submitted: 15 Feb 2023 17:02 Modified: 16 Feb 2023 13:39
Reporter: Colin Mollenhour Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:8.0.21 OS:Linux (Docker)
Assigned to: MySQL Verification Team CPU Architecture:x86 (AMD EPYC 7542)

[15 Feb 2023 17:02] Colin Mollenhour
Description:
I have a simple async replication setup (GTID, row-based) and the slave server crashed while applying an update and continues to crash with the same error on startup so I do not know how to get it running again.
The master has not crashed, thankfully. It is running the exact same Docker image on an AMD EPYC 7402P CPU.

```
2023-02-15T16:16:54.771529Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.21'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server - GPL.
16:16:54 UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7f9d58000b50
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 = 7fa1fe6b9078 thread_stack 0x46000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x557f212db41e]
/usr/sbin/mysqld(handle_fatal_signal+0x31b) [0x557f206e208b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7fa2125da730]
/usr/sbin/mysqld(innobase_get_computed_value(dtuple_t const*, dict_v_col_t const*, dict_index_t const*, mem_block_info_t**, mem_block_info_t*, dict_field_t const*, THD*, TABLE*, dict_table_t const*, upd_t*, dict_foreign_t*)+0xff) [0x557f213d28cf]
/usr/sbin/mysqld(row_upd_store_row(trx_t*, upd_node_t*, THD*, TABLE*)+0x9db) [0x557f2170820b]
/usr/sbin/mysqld(+0x33a90de) [0x557f217090de]
/usr/sbin/mysqld(row_upd_step(que_thr_t*)+0xc33) [0x557f2170c9d3]
/usr/sbin/mysqld(row_update_cascade_for_mysql(que_thr_t*, upd_node_t*, dict_table_t*)+0x9a) [0x557f216c01ba]
/usr/sbin/mysqld(+0x334bc88) [0x557f216abc88]
/usr/sbin/mysqld(row_ins_check_foreign_constraint(unsigned long, dict_foreign_t*, dict_table_t*, dtuple_t*, que_thr_t*)+0x107f) [0x557f216ad80f]
/usr/sbin/mysqld(+0x33a433e) [0x557f2170433e]
/usr/sbin/mysqld(+0x33a94a3) [0x557f217094a3]
/usr/sbin/mysqld(row_upd_step(que_thr_t*)+0xc33) [0x557f2170c9d3]
/usr/sbin/mysqld(+0x3362f95) [0x557f216c2f95]
/usr/sbin/mysqld(row_update_for_mysql(unsigned char const*, row_prebuilt_t*)+0x30) [0x557f216c4650]
/usr/sbin/mysqld(ha_innobase::delete_row(unsigned char const*)+0x1af) [0x557f213b406f]
/usr/sbin/mysqld(handler::ha_delete_row(unsigned char const*)+0x1a8) [0x557f202337d8]
/usr/sbin/mysqld(Delete_rows_log_event::do_exec_row(Relay_log_info const*)+0x30) [0x557f20f66260]
/usr/sbin/mysqld(Rows_log_event::do_apply_row(Relay_log_info const*)+0x26) [0x557f20f64466]
/usr/sbin/mysqld(Rows_log_event::do_index_scan_and_update(Relay_log_info const*)+0x1eb) [0x557f20f7278b]
/usr/sbin/mysqld(Rows_log_event::do_apply_event(Relay_log_info const*)+0x1446) [0x557f20f822a6]
/usr/sbin/mysqld(Log_event::apply_event(Relay_log_info*)+0x8d) [0x557f20f7592d]
/usr/sbin/mysqld(+0x2c810a2) [0x557f20fe10a2]
/usr/sbin/mysqld(+0x2c9077a) [0x557f20ff077a]
/usr/sbin/mysqld(handle_slave_sql+0x2a89) [0x557f20ff3a79]
/usr/sbin/mysqld(+0x34a05f4) [0x557f218005f4]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7fa2125cffa3]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7fa211d794cf]
```

I've experienced a variety of segfaults in other versions (e.g. #108663) so am afraid to upgrade to try the latest version.

How to repeat:
The signal 11 occurs when the server is started (slave is active so replication log is being applied).

We do use a mix of foreign keys, virtual columns, etc.. but I don't know exactly what statement is causing the crash or how to find out.
[16 Feb 2023 13:39] MySQL Verification Team
Hi Mr. Mollenhour,

Thank you for your bug report.

Your bug is a duplicate of the following security bug:

https://bugs.mysql.com/bug.php?id=106327

Since it is a security bug with a test case it will always  remain invisible to the public.

However, it is a verified and not yet fixed bug.

We shall inform you once that it is fixed.