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
Triage: Triaged: D1 (Critical)

[6 Oct 2008 19:16] Hakan Küçükyılmaz
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 ;
[6 Oct 2008 20:29] Ann Harrison
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.
[18 Oct 2008 14:15] Kevin Lewis
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.
[11 Nov 2008 18:00] Kevin Lewis
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.
[11 Nov 2008 18:12] Ann Harrison
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
[17 Mar 2009 1:16] Kevin Lewis
Hakan, has this occurred recently?  If not, let's close it.
[19 Mar 2009 14:47] Hakan Küçükyılmaz
Still happens:

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

Last time: 2009-02-28
[25 Mar 2009 3:46] Kevin Lewis
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.
[25 Mar 2009 14:41] Olav Sandstå
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.
[31 Mar 2009 12:03] John Embretsen
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.
[5 Apr 2009 17:04] Kevin Lewis
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);
[17 Apr 2009 17:03] Olav Sandstå
Fix is in 6.0.11.
[15 May 2009 13:51] MC Brown
Internal/test failure. No changelog entry required.