Bug #42060 Falcon recovery failure - wrong page type, expected 8 got 0 (redoIndexPage)
Submitted: 12 Jan 2009 19:24 Modified: 26 May 2010 17:47
Reporter: Philip Stoev Email Updates:
Status: Unsupported Impact on me:
Category:MySQL Server: Falcon storage engine Severity:S1 (Critical)
Version:6.0-falcon-team OS:Any
Assigned to: Vladislav Vaintroub CPU Architecture:Any
Triage: Triaged: D1 (Critical)

[12 Jan 2009 19:24] Philip Stoev
When executing a recovery after kill -9 on a highly concurrent workload containing a lot of field types, falcon asserted as follows:

# 21:14:03 New table space FALCON_USER, id 1, type 0, filename falcon_user.fts
# 21:14:03 Recovering from lost page inventory page 2
# 21:14:03 New table space FALCON_TEMPORARY, id 2, type 0, filename falcon_temporary.fts
# 21:14:03 Recovering database /build/bzr/6.0-falcon-team/mysql-test/var/master-data_recovery/falcon_master.fts ...
# 21:14:04 first recovery block is 307
# 21:14:04 last recovery block is 456
# 21:14:04 recovery read block is 335
# 21:14:04 === Scavenge Cycle 1 - FALCON_MASTER - 0 seconds
# 21:14:04 6: Activity on /build/bzr/6.0-falcon-team/mysql-test/var/master-data_recovery/falcon_master.fts: 10 fetches, 5 reads, 0 writes, 1 flushWrites
# 21:14:04 6: Activity on /build/bzr/6.0-falcon-team/mysql-test/var/master-data_recovery/falcon_temporary.fts: 0 fetches, 1 reads, 0 writes, 0 flushWrites
# 21:14:04 6: Activity on /build/bzr/6.0-falcon-team/mysql-test/var/master-data_recovery/falcon_user.fts: 1 fetches, 2 reads, 0 writes, 0 flushWrites
# 21:14:06 [Falcon] Error: page 32671/1 wrong page type, expected 8 got 0
# 21:14:06
# 21:14:06 Bugcheck: page 32671/1 wrong page type, expected 8 got 0

my_print_stacktrace+0x32) [0xc40d15]
handle_segfault+0x2a6) [0x6bfe39]
# 21:14:06 /lib64/libpthread.so.0 [0x315b00f0f0]
# 21:14:06 /lib64/libpthread.so.0(raise+0x2b) [0x315b00efab]
Error::debugBreak()+0xe) [0x9de358]
Error::error(char const*, ...)+0x131) [0x9de48b]
Cache::fetchPage(Dbb*, int, PageType, LockType)+0x4cc) [0x9aeda4]
Dbb::fetchPage(int, PageType, LockType)+0x4c) [0x9d395a]
PageInventoryPage::isPageInUse(Dbb*, int)+0x81) [0xa147cf]
Cache::fetchPage(Dbb*, int, PageType, LockType)+0x132) [0x9aea0a]
Dbb::fetchPage(int, PageType, LockType)+0x4c) [0x9d395a]
IndexRootPage::redoIndexPage(Dbb*, int, int, int, int, int, int, unsigned char const*, bool)+0x22a) [0x9f1716]
SRLIndexPage::pass2()+0x19d) [0xa5eef1]
SerialLog::recover()+0x983) [0xa45b03]
Database::openDatabase(char const*)+0x475) [0x9cd28b]
Connection::getDatabase(char const*, char const*, Threads*)+0x16a) [0x9bcc54]
Connection::openDatabase(char const*, char const*, char const*, char const*, char const*, Threads*)+0x1c8) [0x9bdf94]
StorageDatabase::getOpenConnection()+0x89) [0x973cd1]
StorageHandler::initialize()+0xa3) [0x976d6f]
StorageInterface::falcon_init(void*)+0x295) [0x96d71d]
ha_initialize_handlerton(st_plugin_int*)+0xa3) [0x815acb]
plugin_init(int*, char**, int)+0x5d0) [0x8cdab2]
main+0x1eb) [0x6c40b4]
# 21:14:06 /lib64/libc.so.6(__libc_start_main+0xe6) [0x315a41e546]

This is different from bug 41829 because the stack contains IndexRootPage::redoIndexPage and not Dbb::redoDataPage

How to repeat:
If this is repeatable, a test case will be provided. In the meantime, the tablespace before recovery will be uploaded.
[26 Jan 2009 16:02] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:


2974 Vladislav Vaintroub	2009-01-26
      Bug#42060 : Crash in recovery with the message - wrong page type, expected 8 got 0
      The crash happens when recovery finds a page that is supposed to be PageInventoryPage
      but the page is empty(zeroed)
      Prior to crash, inventory page was created but it was not written to disk.
      But, another page with larger page number was flushed. as a result, inventory page
      is filled with zeroes.
      Log creation of the inventory pages. On recovery, recreate then if they are zeroed.