Bug #81859 On win64 the checksums in buf_page_print can be wrong (e.g. none 8030895855 )
Submitted: 15 Jun 2016 10:14
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:5.6.31 OS:Microsoft Windows (x64)
Assigned to: CPU Architecture:Any

[15 Jun 2016 10:14] Shane Bester
Description:
I guess only affects 5.6.  5.7 uses the << streams.

Seen a few times, so wanted to document the number for search purposes.
For the "none" checksum which is hardcoded as:

/** Magic value to use instead of checksums when they are disabled */
#define BUF_NO_CHECKSUM_MAGIC 0xDEADBEEFUL

It sometimes appears in error log as:

,none 8030895855 (which is 0x1DEADBEEF)

Maybe other checksums are wrong too?

How to repeat:
code examination. Looks like fprintf expects 64-bit number, but we're feeding it a 32-bit.

fprintf ULINTPF , BUF_NO_CHECKSUM_MAGIC 

#define BUF_NO_CHECKSUM_MAGIC 0xDEADBEEFUL

#ifdef _WIN64
typedef unsigned __int64	ulint;
typedef __int64			lint;

# define ULINTPF		UINT64PF

#ifdef __WIN__
/* Use the integer types and formatting strings defined in Visual Studio. */
# define UINT32PF	"%I32u"
# define INT64PF	"%I64d"
# define UINT64PF	"%I64u"

Suggested fix:
please use correct types for 64 bit windows
[15 Jun 2016 10:15] Shane Bester
I'm referring to the output when a corruption is found. e.g.

InnoDB: uncompressed page, stored checksum in field1 769419609, calculated checksums for field1: crc32 769419609, innodb 3903488443, none 3735928559, stored checksum in field2 769419609, calculated checksums for field2: crc32 769419609, innodb 3718464063, none 8030895855, page LSN 47 1057076440, low 4 bytes of LSN at page end 1057076440, page number (if stored to page already) 25373, space id (if created with >= MySQL-4.1.1 and stored already) 1931