Bug #112694 | MYSQL master crashes frequently after upgrade from 8.0.28 to 8.0.34 | ||
---|---|---|---|
Submitted: | 12 Oct 2023 0:00 | Modified: | 12 Oct 2023 10:23 |
Reporter: | Uday Kanagala | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server | Severity: | S2 (Serious) |
Version: | 8.0.34 | OS: | Linux |
Assigned to: | CPU Architecture: | Any |
[12 Oct 2023 0:00]
Uday Kanagala
[12 Oct 2023 10:23]
MySQL Verification Team
Hi Mr. Kanagala, Thank you for your bug report. We have searched thoroughly our bug database and we have not found a single bug with a stacktrace remotely similar to yours. Hence, what we require from you is a repeatable test case. This test case should consist of the set of SQL statements that always lead to the problem described. These should include table definitions, a necessary number of rows to repeat the problem and problematic queries themselves. We can not proceed without having all this info. Upgrading within 8.0 version is not known to cause any problems, especially for relatively late releases that you have used. We are waiting on your full feedback.
[6 Nov 2023 15:37]
Piotr Gasiorowski
We have been experiencing the same restart and crashes on MySQL RDS with 8.0.28 too, but so far unable to reproduce locally. This is the query that causes crash and restart: > SELECT * FROM table_systems WHERE type = 'hardware' AND subtype = 'sub17' AND JSON_LENGTH(TPField) = 7 AND JSON_CONTAINS(TPField, '[\"X3718\",\"64142\",\"M5246\",\"U2397\",\"S8326\",\"W6626\",\"P9704\"]') > and the schema on that table is: ``` Create Table: CREATE TABLE `table_systems` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `type` varchar(64) NOT NULL, `subtype` varchar(255) DEFAULT NULL, `TPField` json DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_type` (`type`), KEY `idx_type_subtype` (`type`,`subtype`), KEY `idx_tpfields` ((cast(`TPField` as char(255) array))) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 ROW_FORMAT=DYNAMIC; ```
[7 Nov 2023 10:45]
MySQL Verification Team
Hi Mr. Gasiorowski, Can you supply us with sufficient amount of data so that we can try to repeat the problem ???
[7 Nov 2023 10:47]
MySQL Verification Team
Also, please confirm that the above query is all that it takes to produce a crash. We take crashing bugs very seriously, so we need to be able to reproduce them in order to escalate the problem to the team in charge.
[7 Nov 2023 17:01]
Piotr Gasiorowski
Assertion failure: row0mysql.cc:995:magic2 == ROW_PREBUILT_FETCH_MAGIC_N
Attachment: mysql-error-running.log.2023-11-06.08 (application/octet-stream, text), 166.46 KiB.
[7 Nov 2023 17:05]
Piotr Gasiorowski
I attached detailed crash log with debugging stack trace. If you need any more details please let me know and I will be more than happy to supply. Just to confirm the above SELECT query is NOT the only factor to reproduce it. I have been unable to reproduce it in any way on the production server as well as locally under simulated load while undergoing dynamic buffer resizing, which I initially thought was a related factor.
[8 Nov 2023 11:00]
MySQL Verification Team
Hi Mr. Gasiorowski, Can you supply us with sufficient amount of data so that we can try to repeat the problem ??? We need: * CREATE TABLE statement * INSERT of all rows * SELECT statement itself ........ We are waiting on your feedback.
[9 Nov 2023 9:54]
Piotr Gasiorowski
Seeding table_systems
Attachment: seed.sql (application/octet-stream, text), 3.70 KiB.
[9 Nov 2023 11:35]
MySQL Verification Team
Hi Mr. Gasiorowski, We ran your test case and it worked without any problems. We used our 8.0.35 binary, downloaded from dev.mysql.com. SELECT returned no results what so ever, which is due to how you have defined WHERE conditions in your test case. Can't repeat.
[9 Nov 2023 11:46]
Piotr Gasiorowski
As mentioned previously, the query is not the only factor.
[9 Nov 2023 11:50]
MySQL Verification Team
Hi, As we wrote already, we need a fully repeatable test case. Hence, add the factors that are needed to repeat the problem. Can't repeat.