MySQL Bugs: #39890: Falcon Error: page 0/1 wrong page type, expected 7 got 1

Bug #39890	Falcon Error: page 0/1 wrong page type, expected 7 got 1
Submitted:	6 Oct 2008 19:16	Modified:	15 May 2009 13:51
Reporter:	Hakan Küçükyılmaz	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S1 (Critical)
Version:	6.0-falcon, 6.0-falcon-team	OS:	Any
Assigned to:	Olav Sandstå	CPU Architecture:	Any
Tags:	F_PAGE IO, pushbuild, test failure

Description:
We get an assertion ending in 
Falcon Error: page 0/1 wrong page type, expected 7 got 1

How to repeat:
See Pushbuild
https://intranet.mysql.com/secure/pushbuild/getlog.pl?dir=bzr_mysql-6.0-falcon&entry=Hakan...

Backtrace is:
CURRENT_TEST: falcon.falcon_bug_34617
CURRENT_TEST: falcon.falcon_bug_34890
sql/mysqld(my_print_stacktrace+0x26)[0x8931bd7]
sql/mysqld(handle_segfault+0x2dc)[0x82f1b78][0xffffe420]
sql/mysqld(Error::debugBreak()+0x12)[0x8613734]
sql/mysqld(Error::error(char const*, ...)+0x7a)[0x86137b0]
sql/mysqld(Cache::fetchPage(Dbb*, int, PageType, LockType)+0x3af)[0x85e9c0f]
sql/mysqld(Dbb::fetchPage(int, PageType, LockType)+0x48)[0x860955a]
sql/mysqld(RecordLocatorPage::deleteDataPages(Dbb*, unsigned int)+0x4c)[0x86b5ba2]
sql/mysqld(Section::deleteSectionLevel(Dbb*, int, unsigned int)+0x1a4)[0x865e9da]
sql/mysqld(Section::deleteSection(Dbb*, int, unsigned int)+0x17c)[0x865ffa8]
sql/mysqld(SRLDropTable::commit()+0x44)[0x868437a]
sql/mysqld(SerialLogTransaction::commit()+0x16b)[0x8670649]
sql/mysqld(SerialLogTransaction::doAction()+0x21)[0x867073b]
sql/mysqld(Gopher::gopherThread()+0x1a3)[0x86aa59d]
sql/mysqld(Gopher::gopherThread(void*)+0x11)[0x86aa6d7]
sql/mysqld(Thread::thread()+0x55)[0x85d3e75]
sql/mysqld(Thread::thread(void*)+0x17)[0x85d4081]
/lib/tls/libpthread.so.0[0x400220bd]
/lib/tls/libc.so.6(__clone+0x5e)[0x402609ee]
[Falcon] Error: page 0/1 wrong page type, expected 7 got 1

081006 15:14:22 - mysqld got signal 6 ;

Page zero is supposed to be of type 1.  The problem (this time)
is not in the page, but in the logic that decided that page 0
should be a data page.  There's something wrong in the record
locator page.

Ann, This may also be associated with the Page Inventory Page bug you are investigating.  The other bugs related to wrong page type are Bug#40114 and possibly Bug#39901.  Let me know if you do not think so.

Ann,  I made the other bugs associated with wrong page type to be duplicates of BUG#39458.  They include BUG#40109, BUG#40114 & BUG#39767.  I will leave this one open for now since it was verified by Hakan after the fix for BUG#39458, apparently.  If you think this is no longer a problem, it can be marked duplicate as well.

Let me look a little further.  I suppose it's possible that the other
bug fixed this one - there would have been two page 0's in the cache
during initialization, so it could be.  But page 0 is so special I'd
like to look again

Hakan, has this occurred recently?  If not, let's close it.

Still happens:

https://intranet.mysql.com/secure/pushbuild/xref.pl?startdate=&enddate=&dir=&plat=&testtyp...

Last time: 2009-02-28

Olav, this seems to be a duplicate of both Bug#41626 assigned to Vlad, and Bug#43698 assigned to you.  If you agree, please decide which of these three should remain open and mark the other two as duplicates.  Add messages linking all three together.

Kevin, your are right that the two other bugs are duplicates of this. I have closed Bug#41626 "crash in falcon_bug_34351_C in pushbuild" and Bug#43698  	"Gopher crashes due to wrong page type when reading page into page cache" as duplicates.

Note that the two other bugs have more detailed stack traces than this bug.

According to Olav, falcon_team.falcon_bug_34351_C fails (sometimes) due to this bug. Updating comments in falcon_team suite (see Bug#43982) to reflect this.

Jim Starkey found the problem with the following comment and fix;

"I accidentally produced a before and after snapshot of bug 29890.  It was trivial -- the database was just fine, but a piece of the delete table code (RecordLocatorPage::deleteDataPages, to be specific) was (not) making a call to unlink a space utilization slot.  Boom. "

=== modified file 'storage/falcon/RecordLocatorPage.cpp'
--- storage/falcon/RecordLocatorPage.cpp        2009-03-20 19:28:10 +0000
+++ storage/falcon/RecordLocatorPage.cpp        2009-04-04 22:17:53 +0000
@@ -433,6 +433,7 @@
        for (int slot; (slot = nextSpaceSlot(-1)) >= 0;)
                {
                int pageNumber = elements[slot].page;
+               unlinkSpaceSlot(slot);
                expungeDataPage(pageNumber);
                Bdb *bdb = dbb->fetchPage(pageNumber, PAGE_data, Exclusive);
                BDB_HISTORY(bdb);

Fix is in 6.0.11.

Internal/test failure. No changelog entry required.