fix:Backup using xtrabackup 8.0.30, and then prepare using xtrabackup…

[LI8023NING]

fix:https://perconadev.atlassian.net/browse/PXB-3130

Backup using xtrabackup 8.0.30, and then prepare using xtrabackup 8.0.33. The error is as follows:

InnoDB: Assertion failure: log0recv.cc:4353:log.m_files.find(recovered_lsn) != log.m_files.end()
I0825 22:33:01.738934 05155 ???:1] xtrabackup80 - InnoDB: thread 139988873906432InnoDB: We intentionally generate a memory trap.
I0825 22:33:01.738951 05155 ???:1] xtrabackup80 - InnoDB: Submit a detailed bug report to https://jira.percona.com/projects/PXB.
I0825 22:33:01.738968 05155 ???:1] xtrabackup80 - InnoDB: If you get repeated assertion failures or crashes, even
I0825 22:33:01.738985 05155 ???:1] xtrabackup80 - InnoDB: immediately after the mysqld startup, there may be
I0825 22:33:01.739001 05155 ???:1] xtrabackup80 - InnoDB: corruption in the InnoDB tablespace. Please refer to
I0825 22:33:01.739018 05155 ???:1] xtrabackup80 - InnoDB: http:https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
I0825 22:33:01.739035 05155 ???:1] xtrabackup80 - InnoDB: about forcing recovery.

Through analysis, it was found that it was caused by the type being out of bounds.
Multiple uint32_ The value obtained by multiplying the values of type t is still uint32_ Type t, when the result value is greater than uint32_ After the range that t can represent, an incorrect return value will be obtained

So, type improvement is needed, which has been validated and passed

[LI8023NING]

#ifdef XTRABACKUP
/** Convert block header number to LSN
@param[in] header_num log_block_number
@param[in] start_lsn the current start_LSN set in system
@return LSN number */
inline lsn_t log_block_convert_hdr_to_lsn_no(uint32_t header_num,
lsn_t start_lsn) {
ut_ad(header_num <= LOG_BLOCK_MAX_NO);

uint32_t round_off =
static_cast<uint32_t>(start_lsn / OS_FILE_LOG_BLOCK_SIZE /
LOG_BLOCK_MAX_NO) +
1;
return header_num * OS_FILE_LOG_BLOCK_SIZE * round_off -
OS_FILE_LOG_BLOCK_SIZE;
}
#endif /* XTRABACKUP */

header_num、OS_FILE_LOG_BLOCK_SIZE 、round_off All of them are of type "uint32_t"，The value obtained by multiplication is still of type "uint32_t"。

My test data is as follows:
uint32_t header_num = 963680905
uint32_t OS_FILE_LOG_BLOCK_SIZE = 512
uint32_t round_off = 31

header_num * OS_FILE_LOG_BLOCK_SIZE * round_off -OS_FILE_LOG_BLOCK_SIZE = 1164782592，This is wrong

But when I made a type upgrade to "header_num", it was fine：
uint64_t header_num = 963680905
uint32_t OS_FILE_LOG_BLOCK_SIZE = 512
uint32_t round_off = 31

header_num * OS_FILE_LOG_BLOCK_SIZE * round_off -OS_FILE_LOG_BLOCK_SIZE = 15295543323648

[LI8023NING]

When the LSN is large enough, it must appear

[satya-bodapati]

Thank you for your contribution!