Bug #110269 Server crashed on ALTER TABLE. Now crashes on SELECT.

Description:
Lunching an ALTER command on a table, caused a server crash. Subsequent queries (simple SELECT) still crash the server.
Restarting the server with 'innodb_force_recovery = 3' is still causing crashes. Inreasing the value of 'innodb_force_recovery' over 3 is unfortunately not an option and will not be tested.

LOG OF THE FIRST CRASH (ALTER TABLE):

2023-03-03T08:38:34.033496Z 1452131 [Warning] [MY-010055] [Server] IP address '10.212.134.200' could not be resolved: Name or service not known
InnoDB: Next record offset is nonsensical 65535 in record at offset 101
InnoDB: rec address 0x7ff3743e8065, space id 110, page 0
2023-03-03T09:02:24.709779Z 1453045 [ERROR] [MY-013183] [InnoDB] Assertion failure: page0page.ic:617 thread 140683134310144
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.
09:02:24 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7ff36024e4c0
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 = 7ff3583f0d10 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x55967c1374c1]
/usr/sbin/mysqld(print_fatal_signal(int)+0x2fb) [0x55967afd6fbb]
/usr/sbin/mysqld(my_server_abort()+0x76) [0x55967afd7106]
/usr/sbin/mysqld(my_abort()+0xe) [0x55967c1314be]
/usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x349) [0x55967c3c1f59]
/usr/sbin/mysqld(+0x26a8f4e) [0x55967c51cf4e]
/usr/sbin/mysqld(+0x26aa78b) [0x55967c51e78b]
/usr/sbin/mysqld(dict_stats_update(dict_table_t*, dict_stats_upd_option_t)+0xeff) [0x55967c52291f]
/usr/sbin/mysqld(dict_stats_update(dict_table_t*, dict_stats_upd_option_t)+0xef2) [0x55967c522912]
/usr/sbin/mysqld(ha_innobase::open(char const*, int, unsigned int, dd::Table const*)+0xa14) [0x55967c18dfc4]
/usr/sbin/mysqld(handler::ha_open(TABLE*, char const*, int, int, dd::Table const*)+0x59) [0x55967b0e8139]
/usr/sbin/mysqld(open_table_from_share(THD*, TABLE_SHARE*, char const*, unsigned int, unsigned int, unsigned int, TABLE*, bool, dd::Table const*)+0x1238) [0x55967af81728]
/usr/sbin/mysqld(open_table(THD*, TABLE_LIST*, Open_table_context*)+0x121f) [0x55967add49af]
/usr/sbin/mysqld(+0x1094ecb) [0x55967af08ecb]
/usr/sbin/mysqld(mysql_alter_table(THD*, char const*, char const*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*)+0x51f1) [0x55967af1e061]
/usr/sbin/mysqld(Sql_cmd_alter_table::execute(THD*)+0x4cc) [0x55967b3485cc]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0xa00) [0x55967ae69c30]
/usr/sbin/mysqld(dispatch_sql_command(THD*, Parser_state*)+0x434) [0x55967ae6ea94]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x1d17) [0x55967ae70cd7]
/usr/sbin/mysqld(do_command(THD*)+0x207) [0x55967ae71fd7]
/usr/sbin/mysqld(+0x1153e48) [0x55967afc7e48]
/usr/sbin/mysqld(+0x282ea4d) [0x55967c6a2a4d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8609) [0x7ff395714609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7ff394980163]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7ff3604dd460): is an invalid pointer
Connection ID (thread ID): 1453045
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.
2023-03-03T09:02:25.595618Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.30-0ubuntu0.20.04.2) starting as process 1205145
2023-03-03T09:02:25.612560Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2023-03-03T09:02:26.453559Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2023-03-03T09:02:26.813833Z 0 [System] [MY-010229] [Server] Starting XA crash recovery...
2023-03-03T09:02:26.830966Z 0 [System] [MY-010232] [Server] XA crash recovery finished.

How to repeat:
I was unable to reproduce it.
Connected to a remote server, through a VPN, using DBeaver GUI.
Executed some SELECT statements on MyDb.MyTable (only simple SELECT, with no JOIN).
Using the interface, added and then reordered a column.
ALTER TABLE MyDb.MyTable ADD MyColumn tinyint NULL;
ALTER TABLE MyDb.MyTable CHANGE MyColumn MyColumn tinyint NULL AFTER OtherColumn;

Not the first crash. Recurrent on every select on MyTable

Attachment: select-crash.log (application/octet-stream, text), 8.86 KiB.

First crash

Attachment: alter-crash.log (application/octet-stream, text), 3.91 KiB.

Hi Mrs. Vergani,

Thank you for your bug report.

First of all, the command that crashed your server is definitely ALTER TABLE.

Second, this is a forum for the bug reports with fully repeatable test cases.

Hence, we can not repeat what you experience, unless you send us a set of SQL statements that always lead to the crash, like the above one that you have presented.

We are waiting on your test case.