Bug #29960 Falcon: Crash on two-way running dbt2

• Submitted: 22 Jul 2007 16:43
• Modified: 7 Aug 2007 6:56
• Reporter: Calvin Sun
• Status: Closed
• Category: MySQL Server: Falcon storage engine
• Severity: S1 (Critical)
• Version: 6.0.1
• OS: Linux
• Assigned to: Christopher Powers
• CPU Architecture: Any

[22 Jul 2007 16:43] Calvin Sun

Description:
The following is from Christoffer Hall:

I just ran into a crash running dbt2 on the two-way machine. The backtrace looks like this:

thd: 0xa4ca500
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x987ac4f8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8254974 handle_segfault + 782
0xf73402 (?)
0x8431b14 Error::error(char const*, ...) + 82
0x8431b86 Error::assertionFailed(char const*, int) + 32
0x843ea2c IndexRootPage::redoIndexPage(Dbb*, int, int, int, int, int, int, unsig
ned char const*) + 350
0x8487680 SRLIndexPage::pass2() + 226
0x847235b SerialLog::recover() + 1231
0x84239b0 Database::openDatabase(char const*) + 268
0x8419a0a Connection::getDatabase(char const*, char const*, Threads*) + 224
0x841ba89 Connection::openDatabase(char const*, char const*, char const*, char c
onst*, char const*, Threads*) + 147
0x83f24e6 StorageDatabase::getOpenConnection() + 92
0x83f4ac5 StorageHandler::initialize() + 139
0x83f4da1 StorageHandler::createTable(char const*, char const*, bool) + 139
0x83ee578 StorageInterface::create(char const*, st_table*, st_ha_create_informat
ion*) + 130
0x832f3d3 ha_create_table(THD*, char const*, char const*, char const*, st_ha_cre
ate_information*, bool) + 245
0x82fe6ca rea_create_table(THD*, char const*, char const*, char const*, st_ha_cr
eate_information*, List<create_field>&, unsigned int, st_ + 238
0x836c959 mysql_create_table_no_lock(THD*, char const*, char const*, st_ha_creat
e_information*, Alter_info*, bool, unsigned int) + 2321
0x836cd53 mysql_create_table(THD*, char const*, char const*, st_ha_create_inform
ation*, Alter_info*, bool, unsigned int) + 235
0x826b276 mysql_execute_command(THD*) + 34244
0x826c1c5 mysql_parse(THD*, char const*, unsigned int, char const**) + 707
0x826d0b2 dispatch_command(enum_server_command, THD*, char*, unsigned int) + 380
8
Stack trace seems successful - bottom reached
Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.html 

How to repeat:
run DBT2.

Suggested fix:
do not crash.

[23 Jul 2007 21:55] Christopher Powers

The assertion redoIndexPage is erroneous and will be removed.

Details

This is similar to the (page->level == level - 1) assert in findInsertionLeaf(), which had to be modified to accommodate lateral searches across child pages at the same level.

The difference here is that redoIndexPage() is reconstructing rather than traversing the index. The intent of the assertion is to ensure that the recently fetched parent page resides at a higher level--a reasonable expectation. However, the parent page pointer is redundant not necessarily reliable. From the design doc notes:

"The parent pointer in an index page is not reliable. It is a reliable indicator that the page is not the root of the index, and on new index pages, it does point to the page that is the parent of the new page. However, when a parent page splits some lower level page pointers generally move to the newly created upper level page. Those lower level pages do not have their parent pointers adjusted. The exception implied by 'generally' is that a split at the end of a level leaves existing entries where they are and puts only the new entry in the new page."

Therefore, if a parent page pointer is not reliable, then it should not be validated during index reconstruction from the serial log.

[27 Jul 2007 9:00] Calvin Sun

it is fixed.

[7 Aug 2007 6:56] MC Brown

No documentation needed.