| Bug #109289 | MySQL 8.0.32 corrupted table causing MySQL to crash | ||
|---|---|---|---|
| Submitted: | 6 Dec 2022 8:20 | Modified: | 6 Mar 2023 6:51 |
| Reporter: | Yoseph Phillips | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 8.0.30, 8.0.32 | OS: | Windows (Server 2019) |
| Assigned to: | CPU Architecture: | Any | |
[6 Dec 2022 8:20]
Yoseph Phillips
[6 Dec 2022 12:46]
MySQL Verification Team
Hi Mr. Phillips, Thank you very much for your bug report. However, we need a fully repeatable test case in order to start processing the bug report. However, since you yourself can't repeat it, it is unlikely that we shall get a test case from you that would ALWAYS result in the problem of the bug appearing. In your case it would result in the crash. We have had several very similar reports as this one. In most cases it turned out that there was a temporary glitch in the RAM modules. Those are hardware errors that last for milliseconds and thus can not be identified. That is why we recommend the use of the ECC RAM modules, with parity checking, 2 bits checking and one big correcting. You should consider using those RAM modules. The only other cause of this error can be a low value for the thread stack, which is easily configurable. Can't repeat.
[7 Dec 2022 2:05]
Yoseph Phillips
I have changed this back to S1 (Critical) as this does represent a complete loss of functionality with no known workaround. Please see https://bugs.mysql.com/bug.php?id=108341 which is similar, and impacts both 8.0.30 and 8.0.31 on Windows. We have done this same things hundreds (and possibly thousands) of times on Linux, and also on Windows using older versions of MySQL and never encountered this issue. It certainly looks like a critical regression even though we can't provide a repeatable test case yet. Please ask the developers that did https://bugs.mysql.com/bug.php?id=108341 if they can see if this one is related to that, and if 8.0.32 will fix this issue as well. If this is the case then we would also need to know when this regression was introduced so that we don't upgrade anymore of our Windows clients to a version with this regression. We also are not ruling out hardware issues, but this seems to be too much of a coincidence with known MySQL issues on Windows for 8.0.30 and 8.0.31 and this client just getting upgraded to 8.0.30 soon before this incident.
[7 Dec 2022 5:38]
MySQL Verification Team
https://bugs.mysql.com/bug.php?id=108341 has nothing to do with this bug.
[7 Dec 2022 13:17]
MySQL Verification Team
Hi, Your report and the one that you mention have nothing in common, except that they are both running on Windows. A problem in #!08341 is the usage or jemalloc library, or out-of-the-memory problem. Your problem is the one with Microsoft's STL library , glitch in the hardware or a problem in the thread stack, since MS's STL utilises too much recursions. Thread stack is settable. Can't repeat.
[22 Feb 2023 4:00]
Yoseph Phillips
This has just been reproduced using 8.0.32, also on Windows in a completely different environment. This basically eliminates the hardware failure theory. We are trying to get data for a reproducible test case.
[22 Feb 2023 12:34]
MySQL Verification Team
Hi, We are still unable to reproduce the bug here ...... We need a fully repeatable test case, with our binary, without jemalloc library and with properly setup thread stack.
[6 Mar 2023 6:51]
Yoseph Phillips
This is certainly not easy to reproduce even with the data starting out on the same version of MySQL, and getting upgraded to MySQL 8.0.32 in the same way. We have seen this happen on 2 different Windows environments, and not in others. The binaries are the Windows 64-bit zip archives binaries found on https://dev.mysql.com/downloads/mysql/ The thread stacks will all be at the default as specified on https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_thread_stack. The same queries run on the same data cause this error in certain Windows environments and not others, so it seems that stack size has nothing to do with it. Please let us know if there are specific tests we can do like "SHOW VARIABLES LIKE 'thread_stack';" to isolate what the difference is between different Windows environments. That returns 1048576 in both working and non working environments so we don't believe that is related.
[6 Mar 2023 13:46]
MySQL Verification Team
Hi Mr. Philips, First , we can not do anything with a test case that we can repeat any time that we run it. Second, when querying for system variables, be sure whether you are making a query for global or local variable of the same name ..... This is all explained fully in our Reference Manual.
[6 Mar 2023 13:48]
MySQL Verification Team
Hi, Seems that you need to increase a local thread stack every time that you run that query. When it all finishes, you should revert that change, if the connection is not closed. This looks like a bug in Microsoft's Standard Template Library .......
