MySQL Bugs: #118654: Assertion failure: page0cur.cc:1206 thread 139804775790336

Bug #118654	Assertion failure: page0cur.cc:1206 thread 139804775790336
Submitted:	14 Jul 7:22	Modified:	15 Jul 4:10
Reporter:	VIL North HUB VIL	Email Updates:
Status:	Open	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	8.0.30	OS:	Red Hat (7.9)
Assigned to:	MySQL Verification Team	CPU Architecture:	x86 (48 core)

Description:
We upgraded MYSQL from 5.7.30 to 8.0.30 last week on 05 July 2025. We have master slave configuration 1 master and 1 slave. Our DB is Hadoop cloud meta data. Upgrade works fine up to 12th July 2025. At 12th night application team have planned activity of service version upgrade from their side. We took backup before activity and they started activity. While upgrading their services in between MYSQL server get crashed and give us Assertion failure: page0cur.cc:1206 thread 139804775790336 .We tried innodb_forece_recovery but it could not worked.

2025-07-12T13:46:54.826298Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: page0cur.cc:1206 thread 139804775790336
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.
13:46:54 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
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...

How to repeat:
Need upgraded version of 8.0.30 from 5.7.30 and need to do upgrade from Hadpoop cloud application service version upgrade.

Suggested fix:
Instead of crash need to give error if any MYSQL configuration changes in MYSQL 8.0.30 when upgrade from 5.7.30

Hi,

Proper way to upgrade was to upgrade your 5.7.30 first to 5.7.44 and then from 5.7.44 to 8.0.42

Deprecated configuration parameters are not the reason for crash.

I just tried rather large database upgrade directly from 5.7.30 to 8.0.42 and it worked ok even while not being proper way to do it.

This is a crash because you had corrupted datadir. 

You wrote that you made backup before trying to upgrade. Did you mysqldump or you just copied datadir? Get that system up with 5.7.30 and old datadir if this is how you created backup and try to mysqldump so we can check if the original datadir is ok.

Before upgrade we used util.checkForServerUpgrade() to check possible errors. We don't get any error using it. So we upgraded from 5.7.30 to 8.0.30 directly  firstly on TND(test& development). After that we upgraded on production and it was working fine since a week. On crash day it was planned upgrade activity of application side they updated some service agents from their side that time MYSQL database get crashed. As we have daily backup policy and before activity we also took backup using MYSQLDUMP. in this scenario slave was fine even we confirmed it with mysqlcheck. Then we promoted slave as master and application agent upgrade acivity was done successful. From that slave (which prompted as master) we took backup and restored it on crashed MYSQL server with new datadir and now it working fine. is it bug or if datadir was corrupted what was the reason ? because its working fine since upgrade to 8.0.30. is appellation agent upgrade cause crash/corruption or else something?

Here you can see direct upgrade from 5.7.24 to 8.0.12 on MYSQL official site: 

https://dev.mysql.com/blog-archive/inplace-upgrade-from-mysql-5-7-to-mysql-8-0/