MySQL Bugs: #79713: In-memory corruption of the last 8 bytes of an INDEX page

Bug #79713	In-memory corruption of the last 8 bytes of an INDEX page
Submitted:	20 Dec 2015 13:44	Modified:	14 Apr 2018 14:47
Reporter:	Dennis Buteyn	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.5.46	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	corruption, innodb

Description:
During analysis of my previous bug (http://bugs.mysql.com/bug.php?id=79674) I found that the last 8 bytes of the page dump are corrupted. On disk it shows the sequence "f9d6847139cbad24" whereas MySQL incorrectly shows "000000003b52a8b5".

From what I understand these 8 bytes represent the old checksum and the 32 lowest bits of the LSN. I suspect that these bytes are being reused somewhere for something other than their intended purposes.

How to repeat:
Have MySQL dump an INDEX page to its error log.

Suggested fix:
Don't reuse legacy variables for different purposes.

Image highlighting the corruption in question

Attachment: Screenshot from 2015-12-20 14:12:20.png (image/png, text), 80.41 KiB.

Hello,

Thank you for your bug report.

We do have several questions related to it. In order to verify the bug, we require the entire procedure that lad to the corruption. We need all the tables and commands that will lead to corruption and to the wrong checksum. We can not say, based on your output, that legacy variables have been reused in this case.

Also, we would recommend upgrading to 5.7, following precisely the instructions, which include upgrading to 5.6 first. This is because 5.5 is entering maintenance mode that would limit a range of bugs that would be solved.

Thank you in advance.

Hi!

Couple of additional informations from me. 

InnoDB saves with its page both the new and old checksum, for reasons that I will not elucidate here.

When the page is read, if checksums differ from the calculated ones, InnoDB will exit with verbose info.

So, can you read info from that entire table or not ???

Let me also explain to you, that in 99 % of those cases, it is hardware or OS that is causing the problem. It is so due to many precautions that InnoDB takes to be compatible with ACID standard.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".