[MDEV-28381] InnoDB page number mismatch by 0x100000 Created: 2022-04-21  Updated: 2022-08-01  Resolved: 2022-08-01

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.9
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Cannot Reproduce Votes: 0
Labels: corruption
Environment:

Debian GNU/Linux Sid, x86 (32-bit) user space on AMD64, GCC 11.2.0


 Description   

When testing the fix of MDEV-28371 using its RQG test case on a 32-bit executable, there turned out to be a different bug, reported in CMAKE_BUILD_TYPE=RelWIthDebInfo as follows:

10.9 abe971219456b1f41923c06ff715fd4efeb02850

 
2022-04-21 14:22:17 10 [ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=4294967294, page number=73924], should be [page id: space=4294967294, page number=1122500]
 
2022-04-21 14:22:17 0xd9567ac0  InnoDB: Assertion failure in file /mariadb/10.9/storage/innobase/fsp/fsp0fsp.cc line 1589

The page number difference is exactly 1<<20, a constant that occurs in the function page_id_t::fold(). This failure is independent of the MDEV-28371 fix.

There is a debug assertion in mtr_t::page_lock() that also catches this:

  ut_ad(state < buf_page_t::UNFIXED ||
 
        page_id_t(page_get_space_id(block->page.frame),
 
                  page_get_page_no(block->page.frame)) == block->page.id());

The cause is not obvious to me. cmake -DWITH_UBSAN=ON is not reporting anything before the crash. The test does not fail on 64-bit platforms.

 Comments   
Comment by Marko Mäkelä [ 2022-08-01 ]

I don’t think that 10.8 and 10.9 have changed much in this respect.

Regretfully, I did not write down which compiler version I was using. Today, I tried to repeat this with GCC 12.1.0 and the current 10.8 f79cebb4d02a7b5151ac617bc762c3e094436562. Both Debug and RelWithDebInfo builds of the server passed the test.

I think that we can dismiss this to be something caused by a bug in an early version of GCC 11 or 12.

Generated at Thu Feb 08 10:00:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.