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)
• Status: Verified
• Category: MySQL Server: InnoDB storage engine
• Severity: S3 (Non-critical)
• Version: 5.6.31
• OS: Windows (x64)
• 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] MySQL Verification Team

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