Bug #25564 | MySQL crashes during DROP TABLE after CREATE TABLE ... SELECT * | ||
---|---|---|---|
Submitted: | 11 Jan 2007 23:46 | Modified: | 9 Mar 2007 11:07 |
Reporter: | jocelyn fournier (Silver Quality Contributor) | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Falcon storage engine | Severity: | S1 (Critical) |
Version: | 5.2-Alpha | OS: | Linux (Linux) |
Assigned to: | CPU Architecture: | Any | |
Tags: | qc |
[11 Jan 2007 23:46]
jocelyn fournier
[12 Jan 2007 0:03]
Calvin Sun
READ-UNCOMMITTED is not supported by Falcon. But it should not crash.
[12 Jan 2007 0:13]
jocelyn fournier
Hi, Yes, the warning just says falcon has switched in REPEATABLE READ mode. Jocelyn
[12 Jan 2007 1:15]
jocelyn fournier
With 5.2.1-bk-debug, it even crashes during the CREATE TABLE ... SELECT command, with the following stack : 0x821836d handle_segfault + 479 0x29734825 _end + 553133269 0x29810741 _end + 554034161 0x29731a7b _end + 553121579 0x841523c Error::debugBreak() + 18 0x8415182 Error::error(char const*, ...) + 98 0x8415222 Error::assertionFailed(char const*, int) + 32 0x841a82d Format::Format(ResultSet*) + 445 0x83e090d Table::getFormat(int) + 527 0x83e0273 Table::insert(Transaction*, int, Nfs::Field**, Value**) + 115 0x843524d NInsert::evalStatement(Nfs::Statement*) + 615 0x847df22 Nfs::Statement::start(NNode*) + 166 0x844345b PreparedStatement::executeUpdate() + 145 0x8415de6 Nfs::Field::save() + 738 0x8480310 Nfs::Statement::upgradeTable(Syntax*) + 1610 0x847eada Nfs::Statement::executeDDL() + 188 0x8484736 Nfs::Statement::execute(char const*, bool) + 258 0x847cd9e Nfs::Statement::execute(char const*) + 32 0x840a0db Database::upgradeSystemTables() + 259 0x8407022 Database::openDatabase(char const*) + 1444 0x8402839 Connection::getDatabase(char const*, char const*, Threads*) + 421 0x840052f Connection::openDatabase(char const*, char const*, char const*, char const*, char const*, Threads*) + 401 0x83d5892 StorageDatabase::getOpenConnection() + 138 0x83d48b0 StorageConnection::connect() + 24 0x83d7f22 StorageHandler::getStorageConnection(char const*, THD*, OpenOption) + 598 0x83c660b NfsStorageTable::create(char const*, st_table*, st_ha_create_information*) + 267 0x83143e9 ha_create_table(THD*, char const*, char const*, char const*, st_ha_create_information*, bool) + 483 0x82eb7ae rea_create_table(THD*, char const*, char const*, char const*, st_ha_create_information*, List<create_field>&, unsigned int, st_key*, handler*) + 392 0x832e1a1 mysql_create_table_internal(THD*, char const*, char const*, st_ha_create_information*, List<create_field>&, List<Key>&, bool, unsigned int, bool) + 3375 0x832e4e5 mysql_create_table(THD*, char const*, char const*, st_ha_create_information*, List<create_field>&, List<Key>&, bool, unsigned int, bool) + 401 0x82a322e _Z23create_table_from_itemsP3THDP24st_ha_create_informationP13st_table_listP4ListI12create_fieldEPS5_I3KeyEPS5_I4ItemEPP13st_my + 992 0x82a360b select_create::prepare(List<Item>&, st_select_lex_unit*) + 243 0x8276eba JOIN::prepare(Item***, st_table_list*, unsigned int, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*) + 2612 0x827bd1e _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_sel + 596 0x82763c6 handle_select(THD*, st_lex*, select_result*, unsigned long) + 418 0x8234ad1 mysql_execute_command(THD*) + 4985 0x823d21b mysql_parse(THD*, char*, unsigned int) + 435 0x82320a9 dispatch_command(enum_server_command, THD*, char*, unsigned int) + 2283 0x82317b3 do_command(THD*) + 559 0x823082c handle_one_connection + 1012 0x2972ee51 _end + 553110273 0x298be8aa _end + 554747226
[12 Jan 2007 1:30]
jocelyn fournier
Actually the latest stack only occurs if we try to do the CREATE TABLE ... SELECT in a db corrupted by the previous CREATE TABLE ... SELECT / DROP command.
[12 Jan 2007 12:03]
MySQL Verification Team
Thank you for the bug report. Verified as described.
[24 Jan 2007 17:41]
Hakan Küçükyılmaz
Still hitting an assertion with latest change set. Tried on Linux 32-bit. Program received signal SIGILL, Illegal instruction. [Switching to Thread 1119239088 (LWP 17766)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x40182541 in raise () from /lib/tls/libc.so.6 #2 0x08450c3e in Error::debugBreak () at Error.cpp:93 #3 0x08450c9b in Error::error (string=0x8766f10 "page %d wrong page type, expected %d got %d\n") at Error.cpp:70 #4 0x084cc5d9 in Cache::fetchPage (this=0x402f9ff0, dbb=0x402f9b3c, pageNumber=166, pageType=PAGE_data, lockType=Exclusive) at Cache.cpp:224 #5 0x08446576 in Dbb::fetchPage (this=0x402f9b3c, pageNumber=166, pageType=PAGE_data, lockType=Exclusive) at Dbb.cpp:201 #6 0x08496136 in Section::deleteSectionLevel (dbb=0x402f9b3c, pageNumber=100, transId=0) at Section.cpp:865 #7 0x084962d1 in Section::deleteSection (dbb=0x402f9b3c, sectionId=44, transId=0) at Section.cpp:837 #8 0x084b2716 in SRLDropTable::commit (this=0x42b630cc) at SRLDropTable.cpp:93 #9 0x0849f943 in SerialLogTransaction::commit (this=0x40321b54) at SerialLogTransaction.cpp:70 #10 0x0849fc34 in SerialLogTransaction::doAction (this=0x40321b54) at SerialLogTransaction.cpp:127 #11 0x08499ed2 in SerialLog::gopherThread (this=0x41594614) at SerialLog.cpp:156 #12 0x08499ff2 in SerialLog::gopherThread (arg=0x41594614) at SerialLog.cpp:121 #13 0x0841e269 in Thread::thread (this=0x40300b20) at Thread.cpp:162 #14 0x0841e729 in Thread::thread (parameter=0x40300b20) at Thread.cpp:139 #15 0x40284297 in start_thread () from /lib/tls/libpthread.so.0 #16 0x4021937e in clone () from /lib/tls/libc.so.6 #17 0x42b63bb0 in ?? () (gdb) f 4 #4 0x084cc5d9 in Cache::fetchPage (this=0x402f9ff0, dbb=0x402f9b3c, pageNumber=166, pageType=PAGE_data, lockType=Exclusive) at Cache.cpp:224 224 bdb->pageNumber, pageType, page->pageType); (gdb) l 219 bdb->release(); 220 throw SQLError (DATABASE_CORRUPTION, "page %d wrong page type, expected %d got %d\n", 221 pageNumber, pageType, page->pageType); 222 ***/ 223 FATAL ("page %d wrong page type, expected %d got %d\n", 224 bdb->pageNumber, pageType, page->pageType); 225 } 226 227 // If buffer has moved out of the upper "fraction" of the LRU queue, move it back up 228 (gdb) p pageType $1 = PAGE_data (gdb) p page->pageType Best regards, Hakan
[26 Jan 2007 15:24]
jocelyn fournier
Hi, No more crash with the latest changeset. Thanks, Jocelyn
[26 Jan 2007 16:49]
Jim Starkey
Straight forward space management bug deleting a zero length blob from a full data page. Since the blob was zero length, no space was freed, and DataPage::deleteLine returned the "proper" amount of free space on the page -- none -- which was taken as meaning the page was, in fact, empty and should be deleted.
[9 Mar 2007 11:07]
MC Brown
A note has been added to the 5.2.4 changelog.
[10 Jul 2007 19:10]
MC Brown
This bug report entry has been moved to the 6.0.0 Falcon changelog.