Bug #114466 online ddl and virtual column related crash problems

Description:
The crash stack is triggered when the base column part of the virtual column is updated during online ddl execution (optimize table xx): trx_undo_read_v_cols & row_log_table_apply_op.

2024-03-07T15:27:19.369251Z 0 [Warning] [MY-013865] [InnoDB] Redo log writer is waiting for a new redo log file. Consider increasing innodb_redo_log_capacity.
2024-03-07T15:27:20.123809Z 0 [Warning] [MY-013865] [InnoDB] Redo log writer is waiting for a new redo log file. Consider increasing innodb_redo_log_capacity.
2024-03-07T15:27:21.274941Z 20 [ERROR] [MY-011825] [InnoDB] Cannot drop undo tablespace 'undo_002' because it is active. Please do: ALTER UNDO TABLESPACE undo_002 SET INACTIVE;
2024-03-07T15:27:21.463761Z 0 [Warning] [MY-013865] [InnoDB] Redo log writer is waiting for a new redo log file. Consider increasing innodb_redo_log_capacity.
2024-03-07T15:27:22Z UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=cd3bf925e8466bf8caf97e42a81cab170f309dd6
Thread pointer: 0x7f3508000f80
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 = 7f35682edc70 thread_stack 0x100000
/sda/percona//8.0_source/sql/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x2058d2e]
/sda/percona//8.0_source/sql/bin/mysqld(print_fatal_signal(int)+0x35f) [0xfab6cf]
/sda/percona//8.0_source/sql/bin/mysqld(handle_fatal_signal+0xa5) [0xfab785]
/usr/lib64/libpthread.so.0(+0x135a0) [0x7f359a67f5a0]
/sda/percona//8.0_source/sql/bin/mysqld(trx_undo_read_v_cols(dict_table_t const*, unsigned char const*, dtuple_t const*, bool, bool, unsigned long const*, mem_block_info_t*)+0x142) [0x22d8122]
/sda/percona//8.0_source/sql/bin/mysqld() [0x226ba1a]
/sda/percona//8.0_source/sql/bin/mysqld() [0x226e664]
/sda/percona//8.0_source/sql/bin/mysqld(row_log_table_apply(que_thr_t*, dict_table_t*, TABLE*, Alter_stage*)+0x190) [0x226f420]
/sda/percona//8.0_source/sql/bin/mysqld(bool ha_innobase::inplace_alter_table_impl<dd::Partition>(TABLE*, Alter_inplace_info*)::{lambda(dberr_t)#3}::operator()(dberr_t) const+0x312) [0x21786d2]
/sda/percona//8.0_source/sql/bin/mysqld(bool ha_innobase::inplace_alter_table_impl<dd::Partition>(TABLE*, Alter_inplace_info*)+0x4bb) [0x2178d6b]
/sda/percona//8.0_source/sql/bin/mysqld(ha_innopart::inplace_alter_table(TABLE*, Alter_inplace_info*, dd::Table const*, dd::Table*)+0x101) [0x218a401]
/sda/percona//8.0_source/sql/bin/mysqld() [0xee5c9c]
/sda/percona//8.0_source/sql/bin/mysqld(mysql_alter_table(THD*, char const*, char const*, HA_CREATE_INFO*, Table_ref*, Alter_info*)+0x4df7) [0xefa097]
/sda/percona//8.0_source/sql/bin/mysqld(mysql_recreate_table(THD*, Table_ref*, bool)+0x3b2) [0xefe592]
/sda/percona//8.0_source/sql/bin/mysqld() [0x12f6005]
/sda/percona//8.0_source/sql/bin/mysqld(Sql_cmd_optimize_table::execute(THD*)+0xa9) [0x12f7629]
/sda/percona//8.0_source/sql/bin/mysqld(mysql_execute_command(THD*, bool)+0xb01) [0xe49e71]
/sda/percona//8.0_source/sql/bin/mysqld(dispatch_sql_command(THD*, Parser_state*)+0x4a4) [0xe4da84]
/sda/percona//8.0_source/sql/bin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0xd34) [0xe4ed44]
/sda/percona//8.0_source/sql/bin/mysqld(do_command(THD*)+0x1df) [0xe50f0f]
/sda/percona//8.0_source/sql/bin/mysqld() [0xf9c1a0]
/sda/percona//8.0_source/sql/bin/mysqld() [0x2754625]
/usr/lib64/libpthread.so.0(+0x8f3b) [0x7f359a674f3b]
/usr/lib64/libc.so.6(clone+0x40) [0x7f3599a60840]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f3508370e30): OPTIMIZE TABLE tt_10_p
Connection ID (thread ID): 25
Status: NOT_KILLED

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.
Writing a core file

How to repeat:

Note:The following scenario can reproduce the same stack, but there is no crash. Preliminary analysis, there is no relationship with the partition table, virtual partition, etc.

CREATE TABLE `t1_p` (
  `a` int NOT NULL,
  `b` varchar(24) NOT NULL,
   c  int as(a + 1),
  KEY `k1` (c)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ROW_FORMAT=REDUNDANT COMPRESSION='none'
PARTITION BY RANGE (`a`)
(PARTITION p0 VALUES LESS THAN (1) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (10) ENGINE = InnoDB);
insert into t1_p values(-5, 'good', default);
session1:
optimize table t1_p;
SET DEBUG_SYNC = 'innodb_inplace_alter_table_enter SIGNAL start_create WAIT_FOR go_ahead';
session2:
update t1_p set a = 1;
set debug_sync = 'now signal go_ahead';

Suggested fix:
Open source has fixes for similar issues that I think miss some scenarios.
https://bugs.mysql.com/bug.php?id=108925

Hi Mr. nxxs,

Thank you for your bug report.

First of all, nobody has ever reported a similar crash with our binary.

We have tried to repeat your test case, but our 8.0.36 binary worked without any problems.

Can you, may be, make a MTR test case that would lead to the crash with Oracle's MySQL 8.0.36 binary ???

We can't repeat it as it is .....