Duplicate of fixed in 8.0.34-29

This is fixed by from 8.0.34-29.

The line from stacktrace is not enabled in xtrabackup code. It is not possible at all. (may be someone is forking and forgot to merge this fix ? )

Unless exact steps to reproduce are provided, this cannot be fixed.

ok google translation to English:

RDS2号及RDS7号可以做适当的降配（目前配置为8c32g可降为4c32g）
rds-csyx数据生成目前迁移至polardb并采用压缩的形式，降本接近原来一半
冷库目前在做迁移本地操作
ECS-服务器目前暂未有优化空间

4台ecs 4c16g c盘：100g 数据盘：160g 1台706/月 3台 2118/月 2827200/年

slb 带宽100m 独享 ，带宽10m 665/月 13150/年

rds-mysql 8c32g 存储空间：500g 独享 主备 3500/月 35000/年

1.xtrabackup version 8.0.35-31

2.cat backup-my.cnf

This MySQL options file was generated by innobackupex.

The MySQL server

[mysqld]
innodb_checksum_algorithm=crc32
innodb_log_checksums=1
innodb_data_file_path=ibdata1:200M:autoextend
innodb_log_file_size=1572864000
innodb_log_buffer_size=8388608
innodb_page_size=16384
innodb_undo_directory=./
innodb_undo_tablespaces=2
server_id=2604843235
innodb_log_checksums=ON
innodb_redo_log_encrypt=OFF
innodb_undo_log_encrypt=OFF
server_uuid=8491fb34-5ad7-11ef-90f3-1070fd64e5f4
master_key_id=0
innodb_encrypt_algorithm=aes_256_cbc

3.mysql 8.0

4.2024-08-25T19:40:26.473458+08:00 0 [Note] [MY-012550] [InnoDB] Doing recovery: scanned up to log sequence number 6309043033825
InnoDB: Assertion failure: log0files_capacity.cc:555:file_size <= LOG_FILE_MAX_SIZE
InnoDB: thread 140659171940992InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.percona.com/projects/PXB.
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:
InnoDB: about forcing recovery.
2024-08-25T11:40:26Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=
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
/u01/xtrabackup80/bin/xtrabackup(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x25293ee]
/u01/xtrabackup80/bin/xtrabackup(print_fatal_signal(int)+0x373) [0x13330a3]
/u01/xtrabackup80/bin/xtrabackup(handle_fatal_signal+0x95) [0x1333175]
/lib64/libpthread.so.0(+0xf630) [0x7fedc3b8b630]
/lib64/libc.so.6(gsignal+0x37) [0x7fedc19a5387]
/lib64/libc.so.6(abort+0x148) [0x7fedc19a6a78]
/u01/xtrabackup80/bin/xtrabackup(my_abort()+0xa) [0x25231aa]
/u01/xtrabackup80/bin/xtrabackup(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0xe8) [0x180c1b8]
/u01/xtrabackup80/bin/xtrabackup(Log_files_capacity::next_file_size(unsigned long)+0x78) [0x18320b8]
/u01/xtrabackup80/bin/xtrabackup(Log_files_capacity::next_file_earlier_margin(unsigned long)+0x9) [0x18320f9]
/u01/xtrabackup80/bin/xtrabackup(Log_files_capacity::hard_logical_capacity_for_physical(unsigned long)+0x4f) [0x183221f]
/u01/xtrabackup80/bin/xtrabackup(Log_files_capacity::update(Log_files_dict const&, unsigned long, unsigned long)+0x3c) [0x183301c]
/u01/xtrabackup80/bin/xtrabackup() [0x1838bad]
/u01/xtrabackup80/bin/xtrabackup(log_files_start(log_t&)+0x1a3) [0x183cdc3]
/u01/xtrabackup80/bin/xtrabackup(log_start(log_t&, unsigned long, unsigned long, unsigned char*, bool)+0x2fe) [0x16bb06e]
/u01/xtrabackup80/bin/xtrabackup(recv_recovery_from_checkpoint_start(log_t&, unsigned long, unsigned long)+0x1228) [0x16dc7b8]
/u01/xtrabackup80/bin/xtrabackup(srv_start(bool, unsigned long)+0x1650) [0x17b4d50]
/u01/xtrabackup80/bin/xtrabackup() [0xdbafdb]
/u01/xtrabackup80/bin/xtrabackup() [0xdbc45d]
/u01/xtrabackup80/bin/xtrabackup(main+0x1194) [0xd53c14]
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7fedc1991555]
/u01/xtrabackup80/bin/xtrabackup() [0xd8a739]

Please provide more details

1. xtrabackup version

2. size of redolog file in backupdir (xtrabackup_logfile)

3. server version

4. xtrabckup error log