MySQL Bugs: #111063: Assert: !dummy_big_rec on rollback of delete or update of row

Bug #111063	Assert: !dummy_big_rec on rollback of delete or update of row_format=compressed.
Submitted:	17 May 2023 20:39	Modified:	30 May 2023 20:46
Reporter:	Jean-François Gagné	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	5.7.42, 8.0.31, 8.0.32, 8.0.33	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Hi, this is not a simple one...

I have MySQL crashing with below in the error logs of 5.7.42 when rolling-back the delete of a very specific row in a table with row_format=compressed.  Rolling-back an update leads to the same crash.  The full stack trace from the logs is in the comments.

2023-05-17 19:39:29 0x7f5424235700  InnoDB: Assertion failure in thread 139999360276224 in file row0umod.cc line 159
InnoDB: Failing assertion: !dummy_big_rec

Interestingly, the content of the logs are different for a debug build, full stack trace in the comments.

2023-05-17 20:04:48 0x7f12780f6700  InnoDB: Assertion failure in thread 139717300414208 in file btr0cur.cc line 4411
InnoDB: Failing assertion: flags & BTR_KEEP_POS_FLAG

Quick note: once this problem is identified in a table, rebuilding the table (ALTER TABLE ... FORCE) makes the problem go away.

If the rollback is done immediately after the delete or update, MySQL will probably recover.  If I wait more than one second between the delete/update and the rollback, MySQL will crash again during crash recovery.  I suspect the delete or update not getting in the redo logs allows MySQL to recover, but when it gets there, crash recovery will apply the dml and then try rolling it back, which will lead to another crash and the impossibility to recover (I did not try to force InnoDB recovery).  And this - unrecoverable data corruption - is why I report this as a S1 (Critical) bug.

This looks very similar to Bug#93768.

I do not have a repeatable test-case starting from a new MySQL instance.  See private comment for more information about reproductivity.

The way I reproduce the crash is by exporting a table from an affected instance (FLUSH TABLE ... FOR EXPORT) and importing it in an empty dbdeployer sandbox.  The table comes from a 5.7 Percona Server for MySQL instance and it was imported in a MySQL sandbox (not Percona Server).  For privacy and compliance reasons, I cannot share the full table, but I still have a way to "show" you this crash.

Marko Mäkelä, who was super helpful in troubleshooting this - many thanks Marko, created a fake ibd file from an uncompressed page I was able to extract from the memory of a running mysqld instance under gdb.  With this file that I share privately, the crash can be reproduced by deleting or updating a specific row.  Note that SELECT * on this row works, but SELECT * on the whole table does not work and crashes MySQL because the fake file is not complete and fails on off-page blog storage lookup.

I was able to reproduce similar crashes with 8.0.31, both non-debug and debug build lead to below, full stack trace in the comments.

2023-05-17T20:09:57.450326Z 8 [ERROR] [MY-013183] [InnoDB] Assertion failure: row0umod.cc:152:!dummy_big_rec || node->table->has_row_versions() thread 139815347488512

But 8.0.32 do not crash with a non-debug build.  I suspect the fix for Bug#34558510 partially solved the problem, and I insist on partially, because a debug build of 8.0.32 and 8.0.33 crashes with below on the rollback of a delete, full stack trace in the comments, but the rollback of an update does not crash a debug build.

2023-05-17T19:45:18.472386Z 8 [ERROR] [MY-013183] [InnoDB] Assertion failure: mem0mem.ic:191:*no_mans_land_it == mem_no_mans_land_byte thread 140473013794560

Let me know if you need more information to troubleshoot this (I will happily provide gdb or other information that can help narrowing-down this bug).

Many thanks for looking into this,

Jean-François Gagné

How to repeat:
Using the fake ibd and sql file in private comment...

dbdeployer deploy single mysql_5.7.42
./use <<< "create database test_jfg"
cat fake.sql | ./use test_jfg
./use test_jfg <<< "alter table fake discard tablespace"
cp /tmp/fake.ibd data/test_jfg/fake.ibd
./use test_jfg <<< "alter table fake import tablespace"

# :id is in the private comment.
./use test_jfg <<< "begin; delete from fake where id = :id; rollback;"
./use test_jfg <<< "begin; update fake set sourceBranchId = 0 where id = :id; rollback;"

Full stack trace for the rollback of a delete in a non-debug build of 5.7.42:

2023-05-17 19:39:29 0x7f5424235700  InnoDB: Assertion failure in thread 139999360276224 in file row0umod.cc line 159
InnoDB: Failing assertion: !dummy_big_rec
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/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
19:39:29 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68199 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x2e65f60
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 = 7f5424234e88 thread_stack 0x40000
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(my_print_stacktrace+0x35)[0xf83e25]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(handle_fatal_signal+0x4b9)[0x800999]
/lib64/libpthread.so.0(+0x12cf0)[0x7f54476dfcf0]
/lib64/libc.so.6(gsignal+0x10f)[0x7f5445fe2aff]
/lib64/libc.so.6(abort+0x127)[0x7f5445fb5ea5]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z18ut_print_timestampP8_IO_FILE+0x0)[0x7ef92e]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x149293b]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1492f69]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z12row_undo_modP11undo_node_tP9que_thr_t+0x25a)[0x1494c7a]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z13row_undo_stepP9que_thr_t+0x6c)[0x132380c]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z15que_run_threadsP9que_thr_t+0x870)[0x12bd620]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x136529f]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1365d16]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z22trx_rollback_for_mysqlP5trx_t+0x12a)[0x13693ca]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x122c617]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z15ha_rollback_lowP3THDb+0xa7)[0x8506f7]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z17ha_rollback_transP3THDb+0x8e)[0x85050e]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z14trans_rollbackP3THD+0x3a)[0xe00a9a]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z21mysql_execute_commandP3THDb+0x247c)[0xd4611c]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x3fd)[0xd4904d]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x16f8)[0xd4a888]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z10do_commandP3THD+0x194)[0xd4b434]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(handle_connection+0x2ac)[0xe1e97c]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(pfs_spawn_thread+0x174)[0x1151384]
/lib64/libpthread.so.0(+0x81ca)[0x7f54476d51ca]
/lib64/libc.so.6(clone+0x43)[0x7f5445fcde73]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (2e7b1e0): rollback
Connection ID (thread ID): 2
Status: NOT_KILLED

Full stack trace for the rollback of a delete in a debug build of 5.7.42:

2023-05-17 20:04:48 0x7f12780f6700  InnoDB: Assertion failure in thread 139717300414208 in file btr0cur.cc line 4411
InnoDB: Failing assertion: flags & BTR_KEEP_POS_FLAG
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/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
20:04:48 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68206 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f125800b220
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 = 7f12780f5e10 thread_stack 0x40000
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(my_print_stacktrace+0x35)[0x1924266]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(handle_fatal_signal+0x407)[0xf0b6cb]
/lib64/libpthread.so.0(+0x12cf0)[0x7f1286265cf0]
/lib64/libc.so.6(gsignal+0x10f)[0x7f1284b68aff]
/lib64/libc.so.6(abort+0x127)[0x7f1284b3bea5]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1e500ef]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z26btr_cur_pessimistic_updatemP9btr_cur_tPPmPP16mem_block_info_tS4_PP9big_rec_tP5upd_tmP9que_thr_tmP5mtr_t+0x8c4)[0x1e8581f]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1fc094f]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1fc101a]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z12row_undo_modP11undo_node_tP9que_thr_t+0x2f3)[0x1fc3614]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1dc4dc3]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z13row_undo_stepP9que_thr_t+0xb5)[0x1dc5020]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1d17d4b]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1d17f67]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z15que_run_threadsP9que_thr_t+0x92)[0x1d18129]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1e2d989]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1e2dc6b]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1e2df4a]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z22trx_rollback_for_mysqlP5trx_t+0x53)[0x1e2e2a3]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld[0x1c0d0c8]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z15ha_rollback_lowP3THDb+0x13c)[0xf88c29]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_ZN12TC_LOG_DUMMY8rollbackEP3THDb+0x27)[0x16d0457]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z17ha_rollback_transP3THDb+0x135)[0xf88ebf]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z14trans_rollbackP3THD+0xc1)[0x16d2e89]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z21mysql_execute_commandP3THDb+0x55ed)[0x15d18bf]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x7d5)[0x15d5397]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0xe6a)[0x15c9c0c]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(_Z10do_commandP3THD+0x4b3)[0x15c88ae]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(handle_connection+0x1e7)[0x1702695]
/home/jgagne/opt/mysql/mysql_5.7.42/bin/mysqld(pfs_spawn_thread+0x170)[0x1afc724]
/lib64/libpthread.so.0(+0x81ca)[0x7f128625b1ca]
/lib64/libc.so.6(clone+0x43)[0x7f1284b53e73]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f125800fdc0): rollback
Connection ID (thread ID): 2
Status: NOT_KILLED

Full stack trace for the rollback of a delete in a non-debug and a debug build of 8.0.31:

2023-05-17T20:09:57.450326Z 8 [ERROR] [MY-013183] [InnoDB] Assertion failure: row0umod.cc:152:!dummy_big_rec || node->table->has_row_versions() thread 139815347488512
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.
2023-05-17T20:09:57Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=53d8f46f67d9f61e2a8d9ba6b79c874d195fcd66
Thread pointer: 0x7f29533eb780
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 = 7f294c1efc60 thread_stack 0x100000
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x206ab2e]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(print_fatal_signal(int)+0x3c3) [0x110a893]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(my_server_abort()+0x5e) [0x110a99e]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(my_abort()+0xa) [0x2064eea]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x30c) [0x234221c]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld() [0x252e380]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld() [0x252e919]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(row_undo_mod(undo_node_t*, que_thr_t*)+0xca7) [0x2532027]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(row_undo_step(que_thr_t*)+0x52) [0x22be332]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(que_run_threads(que_thr_t*)+0xb48) [0x22625e8]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld() [0x2317767]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld() [0x231a864]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(trx_rollback_for_mysql(trx_t*)+0x260) [0x231ae00]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld() [0x2152d5a]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(ha_rollback_low(THD*, bool)+0x12e) [0x120a64e]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(trx_coordinator::rollback_in_engines(THD*, bool)+0x25) [0x10bdf05]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(MYSQL_BIN_LOG::rollback(THD*, bool)+0xcf) [0x1ca588f]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(ha_rollback_trans(THD*, bool)+0x7a) [0x120a81a]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(trans_rollback(THD*)+0x4e) [0x10c01be]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(mysql_execute_command(THD*, bool)+0xf26) [0xfa45e6]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(dispatch_sql_command(THD*, Parser_state*)+0x403) [0xfa7fa3]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x2048) [0xfaa4f8]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld(do_command(THD*)+0x1df) [0xfab55f]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld() [0x10fb0d8]
/home/jgagne/opt/mysql/mysql_8.0.31/bin/mysqld() [0x27e7c7a]
/lib64/libpthread.so.0(+0x81ca) [0x7f2965bc31ca]
/lib64/libc.so.6(clone+0x43) [0x7f2963cfee73]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f2953386e10): rollback
Connection ID (thread ID): 8
Status: NOT_KILLED

Full stack trace for the rollback of a delete in the debug build of 8.0.33:

2023-05-17T20:00:15.899215Z 8 [ERROR] [MY-013183] [InnoDB] Assertion failure: mem0mem.ic:191:*no_mans_land_it == mem_no_mans_land_byte thread 140221837788928
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.
2023-05-17T20:00:15Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=71ec166fb7f6bfb89d7e3536a54c9ed9a5d33902
Thread pointer: 0x7f8808659170
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 = 7f87f0d4bb78 thread_stack 0x100000
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x31) [0x3f9301c]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(print_fatal_signal(int)+0x2de) [0x3236446]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(my_server_abort()+0x5f) [0x3236656]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(my_abort()+0xa) [0x3f8c9f0]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x15a) [0x422d83a]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x42399c2]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(mem_heap_block_free(mem_block_info_t*, mem_block_info_t*)+0x109) [0x4239d22]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x41a619c]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x41a62a6]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x41a6e42]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(row_undo_step(que_thr_t*)+0x67) [0x41a7962]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x412b1e3]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x412b3d6]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(que_run_threads(que_thr_t*)+0x8e) [0x412b536]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x420af10]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x420b400]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x420b5bb]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(trx_rollback_for_mysql(trx_t*)+0x41) [0x420b7d6]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x3fde1ee]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(ha_rollback_low(THD*, bool)+0x1d2) [0x3354d1f]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(trx_coordinator::rollback_in_engines(THD*, bool)+0x7a) [0x31dd93a]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(MYSQL_BIN_LOG::rollback(THD*, bool)+0x181) [0x3c9a5fd]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(ha_rollback_trans(THD*, bool)+0xac) [0x3350073]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(trans_rollback(THD*)+0xa3) [0x31e0909]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(mysql_execute_command(THD*, bool)+0x3058) [0x30c3e14]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(dispatch_sql_command(THD*, Parser_state*)+0x511) [0x30c5dc9]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x133a) [0x30c752b]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld(do_command(THD*)+0x475) [0x30c926e]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x3227bb7]
/home/jgagne/opt/mysql/mysql_8.0.33/bin/mysqld() [0x4743af9]
/lib64/libpthread.so.0(+0x81ca) [0x7f88275121ca]
/lib64/libc.so.6(clone+0x43) [0x7f882564be73]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f8809044840): rollback
Connection ID (thread ID): 8
Status: NOT_KILLED

Bonjour Mr. Gagne,

Thank you very much for your bug report.

We can confirm that your bug report is a duplicate of the following bug report:

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

That bug report is hidden, just like yours, since these are Security Vulnerability bug. 

The original bug is hidden even more, since it contain the entire repeatable test case, while yours only has some recommendations on how to repeat. 

Since you can not inspect the original bug report, we have left a message in it that this report is also informed when the original bug is fixed.

Duplicate.

Thanks for the explanation for hiding this bug.

You should know that there is already public information out there about this bug, below is a quick list:

https://mysqlcommunity.slack.com/archives/C8Y94HRMX/p1678719924358409

https://mariadb.zulipchat.com/#narrow/stream/118759-general/topic/InnoDB.20Rollback.20Bug/...

https://jira.mariadb.org/browse/MDEV-30882

Bon jour Mr. Gagne,

We have to change the status of this report, since it turns out that this is not a duplicate.

However, we need to be able to repeat the crash that you are reporting. For that we need a test case, preferably with our own tools.

We shall also take a deep look in the other links that you have mentioned.

Thanks for the update about "not a duplicate".

About repeatable test-case, I tend to agree that the way I report this bug is sub-optimal, but I am already providing you all what I have and I hardly see how I could do more.  FYI, I tried generating the rollback crash in a new environment, but without success, and I would guess that a skilled InnoDB Developper might gather enough evidence in the fake file I share to craft a repro.

About the "Can't repeat", would you consider unhiding this bug ?  After all, a "Can't repeat" is hardly a security vulnerability, and we need more eyes on this to come-up with a repro.

Many thanks, J-F

Hi,

This bug is not hidden any more .......

We shall continue to look for the ways on how this behaviour can be provoked ......

In case it is interesting to some people following this bug, I ran both 5.7.42 and 8.0.33 debug binaries under gdb with a breakpoint in page_zip_compress.  With this breakpoint, I run below.

./use test_jfg <<< "begin; delete from fake where id = :id; rollback;"

Once getting to the breakpoint (this shows this problem is related to a compression / compaction), do a backtrace and I "finish" until getting to the SIGABRT.

Maybe someone this would mean something to someone.  the gdb outputs are in the next 2 attached files.

mysql_5.7.42_gdb.txt

Attachment: mysql_5.7.42_gdb.txt (text/plain), 14.90 KiB.

mysql_8.0.33_gdb.txt

Attachment: mysql_8.0.33_gdb.txt (text/plain), 18.05 KiB.

Merci, Jean Francois !!!!